Model training method, electronic device, readable storage medium and program product

Abstract

This application discloses a model training method, electronic device, readable storage medium, and program product, relating to the field of artificial intelligence technology. The method includes: acquiring trigger-action metadata and scene configuration conditions; determining multiple scene prompt templates corresponding to the trigger-action metadata and satisfying the scene configuration conditions, and filling the trigger-action metadata into the multiple scene prompt templates to generate multiple model input prompts; calling a large language model and acquiring multiple initial sample data generated by the large language model based on the multiple model input prompts; and post-processing the multiple initial sample data to obtain multiple target sample data, wherein the target sample data is used for model training. This application achieves fully automated generation of training data for conditionally triggered tasks through a multi-module cascaded data generation pipeline, improving data generation efficiency and quality.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, specifically to a model training method, electronic device, readable storage medium and program product, and in particular to a method for generating training data and training models for conditionally triggered tasks. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology, smart terminal assistants are evolving from simple command execution to the generation of complex automated workflows. In application scenarios such as YOYO tasks, users expect electronic devices to automatically understand and generate automated processes that include appointments, conditional triggers, and multi-step execution, simply by describing their needs in natural language. These processes cover complex scenarios such as automatic check-in, cross-brand IoT control, commuting assistance, and health management.

[0003] However, building conditional execution agents capable of supporting these complex scenarios presents significant data engineering challenges. Real-world business scenarios involve over 10 types of complex scenarios, tens of thousands of data points, and more than 400 extended tools, requiring deep integration of personal knowledge bases, proactive services, graphical user interface (GUI) interactions, and customized logic such as list selection. Current data generation and processing models are ill-suited to meet these business demands of "high-frequency iteration and high generalization."

[0004] The conventional technical solutions have the following shortcomings: First, they lack a universal and scalable data structure for condition-triggered tasks. Existing data formats are usually designed for single task scenarios and are difficult to simultaneously support multiple capabilities such as single / multiple triggers, single / multiple actions, conditional logic judgments, repeated execution, skill loading, and external knowledge base queries. Second, the data generation efficiency for condition-triggered tasks is low and the quality is unstable. Manual annotation is slow and has a high rework rate. Traditional data synthesis links generate data based on query statements and tool calls simultaneously, resulting in poor scalability, weak scenario adaptability, and severe model illusion. Third, they lack a layered data verification mechanism for condition-triggered tasks. Existing data verification relies heavily on manual review of each item, which is costly and inefficient.

[0005] Therefore, it is currently difficult to construct training data for complex condition-triggered tasks, resulting in insufficient understanding and execution capabilities of intelligent agents in multi-task and multi-condition-triggered scenarios. Summary of the Invention

[0006] This application provides a model training method, electronic device, readable storage medium, and program product. Through a multi-module cascaded data generation pipeline, it achieves fully automated generation of training data for conditionally triggered tasks, thereby improving data generation efficiency and quality.

[0007] In a first aspect, this application provides a model training method, which includes: acquiring trigger-action metadata and scene configuration conditions; determining multiple scene prompt templates that correspond to the trigger-action metadata and satisfy the scene configuration conditions, and filling the trigger-action metadata into the multiple scene prompt templates to generate multiple model input prompts; calling a large language model and acquiring multiple initial sample data generated by the large language model based on the multiple model input prompts; and post-processing the multiple initial sample data to obtain multiple target sample data, wherein the target sample data is used for model training.

[0008] Through the above four-step process, the entire process of producing training data for condition-triggered tasks—from seed data construction, scene template matching, large language model generation to post-processing—is automated, solving the problems of low efficiency and insufficient scene coverage in manual annotation.

[0009] In one possible implementation of the first aspect above, obtaining trigger-action metadata includes: obtaining a tool definition and a tool common scenario slot mapping table. The tool definition includes at least one of a tool identifier, a tool description, and a parameter list. The tool common scenario slot mapping table includes at least one common scenario corresponding to each tool and its slot value template. Iterate through each tool in the tool definition and match the common scenario corresponding to each tool according to the tool common scenario slot mapping table. For each matched common scenario, instantiate the slot according to the slot value template to obtain the corresponding parameter value. Generate trigger conditions based on the scenario description and the instantiated parameter value, and generate an execution action based on the tool identifier and the instantiated parameter value. Pair and combine the trigger conditions and the execution action to obtain trigger-action metadata.

[0010] By automatically constructing trigger-action metadata through tool definition and slot mapping tables, seed data can be generated on a large scale and in a standardized manner, ensuring the semantic matching accuracy between trigger conditions and execution actions, and significantly improving seed data production efficiency.

[0011] In one possible implementation of the first aspect above, the scene configuration conditions include a scene description, a list of available tools, and interaction constraints; determining multiple scene prompt templates that correspond to the trigger-action metadata and satisfy the scene configuration conditions includes: determining the target scene category based on the trigger conditions and execution actions in the trigger-action metadata; obtaining the scene configuration conditions corresponding to the target scene category from a preset scene configuration library; and dynamically selecting multiple scene prompt templates that satisfy the scene configuration conditions from the scene configuration library according to a preset scene generation ratio.

[0012] By configuring scenario configuration conditions through three dimensions—scenario description, list of available tools, and interaction constraints—the scope of scenarios and interaction rules for data generation can be precisely constrained, ensuring that the generated data conforms to the semantic boundaries of the target scenario. Templates can be dynamically selected based on the scenario generation ratio, which can precisely control the distribution ratio of various scenario data and avoid model bias.

[0013] In one possible implementation of the first aspect mentioned above, the scene prompt template is stored in the form of prompt words and skills, and can be added or deleted.

[0014] The system uses both prompt and skill methods to store scene prompt templates, and supports flexible addition and deletion, which improves the scalability of the data generation system and facilitates the rapid integration of new scene types.

[0015] In one possible implementation of the first aspect mentioned above, the scene prompt template includes a modal word configuration, a sentence template, and a character description, which are used to guide the large language model to generate dialogue data that conforms to the target scene category; the trigger-action metadata is filled into multiple scene prompt templates to generate multiple model input prompts, including: using the trigger conditions and execution actions in the trigger-action metadata as slot values, filling them into the corresponding slots of each scene prompt template to generate multiple model input prompts.

[0016] By configuring interjections, sentence templates, and character descriptions, the large language model is guided to generate dialogue data, ensuring that the generated user query statements conform to the expression habits and interaction characteristics of the target scenario; slot filling is used to generate model input prompts to ensure the semantic anchoring effect of triggering conditions and execution actions in the generation process.

[0017] In one possible implementation of the first aspect above, calling a large language model and obtaining multiple initial sample data generated by the large language model based on multiple model input prompts includes: for different scenario prompt templates, calling different large language model interfaces in parallel to generate data, and obtaining multiple initial sample data generated by each language model based on the corresponding model input prompts.

[0018] By calling different large language model interfaces in parallel for different scenario prompt templates, the diversity of user query expression is increased, the generalization of training data is enhanced, and data generation time is saved through parallel calls.

[0019] In one possible implementation of the first aspect above, the large language model generates multiple initial sample data based on multiple model input prompts, including: generating user query statements by reverse engineering from the standard answer corresponding to the trigger-action metadata; and generating user query statements corresponding to the standard answer by the large language model based on the trigger conditions and execution actions in the trigger-action metadata, which are then used as user query statements in the initial sample data.

[0020] By adopting the GT→Query reverse generation method, user query statements are generated in reverse based on the standard answer of the triggering conditions and execution actions. Compared with the forward generation method that generates query statements and tool calls at the same time, it can significantly reduce model illusion and improve data quality.

[0021] In one possible implementation of the first aspect above, the initial sample data includes user query statements, model responses, and tool call examples; the scenario type corresponding to the initial sample data includes at least one of the following: simple scenario, logical AND / OR scenario, multi-action scenario, follow-up question scenario, rejection scenario, independent multi-task scenario, multi-round modification scenario, and multi-round addition scenario.

[0022] By covering various scenario types, including simple scenarios, logical AND / OR scenarios, multi-action scenarios, follow-up questioning scenarios, rejection scenarios, independent multi-task scenarios, multi-round modification scenarios, and multi-round addition scenarios, the coverage of training data in complex scenarios is improved, and the scenario adaptability of the task model is enhanced.

[0023] In one possible implementation of the first aspect above, multiple initial sample data are post-processed to obtain multiple target sample data, including: parsing the initial sample data to extract tool call information and scene feature information; matching the tool call information with a preset tool set and matching the scene feature information with a preset scene category; determining the successfully matched initial sample data as data to be enhanced, performing multi-round interactive expansion on the data to be enhanced, generating multi-round interactive logic including at least one of confirmation rounds, parameter inquiry rounds, modification rounds, and result feedback rounds, to obtain enhanced data.

[0024] By parsing the initial sample data and matching it with a preset set of tools and scenario categories, data that can be enhanced is selected. Through multi-round interaction, multi-round interaction logic including confirmation rounds, parameter inquiry rounds, modification rounds, and result feedback rounds is generated, which generates complex multi-round interaction data that is difficult for large language models to generate in one step, significantly improving the coverage of training data in multi-round interaction scenarios.

[0025] In one possible implementation of the first aspect above, multi-round interactive expansion of the data to be enhanced includes: determining the types of additional interaction rounds based on the triggering conditions and execution actions in the data to be enhanced; selecting corresponding scene templates from a preset scene template library based on the interaction round types, wherein scene templates are stored in the form of prompt words and skills, and can be added or deleted; generating supplementary interaction round data based on the scene templates and contextual information in the data to be enhanced; and concatenating the supplementary interaction round data with the data to be enhanced to obtain enhanced data containing multi-round interactive logic.

[0026] By determining the types of additional interaction rounds based on triggering conditions and execution actions, and selecting corresponding scene templates to generate additional round data, the automation and precision of multi-round interaction expansion are achieved; scene templates can be added and deleted, improving the scalability of multi-round interaction expansion.

[0027] In one possible implementation of the first aspect above, after the augmented data is obtained by multi-round interactive expansion of the data to be augmented, the method further includes: for augmented data that requires the assistance of auxiliary tools, performing tool post-processing, which includes: calling an external knowledge base to obtain tool description information corresponding to the auxiliary tool; performing reasoning based on the tool description information to generate query information; executing a query based on the query information to obtain query results; and updating the augmented data based on the query information and query results to make the updated data conform to the format requirements of the auxiliary tool.

[0028] By calling external knowledge bases to obtain tool description information and inferring query information, executing queries to obtain query results, and then updating and enhancing data, we can ensure that the semantics of task data that requires the assistance of tools are complete and the format is standardized, thereby improving the data quality of scenarios related to assistance tools.

[0029] In one possible implementation of the first aspect above, after the augmented data is obtained by multi-round interactive expansion of the data to be augmented, the method further includes: for augmented data that hits a set scenario (also known as a specific scenario), performing set scenario post-processing, which includes: identifying the set scenario type corresponding to the augmented data, where the set scenario type includes at least one of personal knowledge base scenario, address list selection scenario, and workflow modification scenario; calling the scenario post-processing template corresponding to the set scenario type; updating the augmented data according to the preset scenario branch ratio to generate training data containing complex rounds of interaction and multiple branches of sub-scenarios; wherein, the scenario branches include at least one of address query being empty, address query being multiple, query being abnormal, and query result being unique, and different scenario branches correspond to different orchestration and interaction logic.

[0030] By performing customized post-processing for personal knowledge base scenarios, address list selection scenarios, and workflow modification scenarios, training data containing complex rounds of interaction and multiple branches of sub-scenarios is generated, improving the data generation effect of the set scenarios. The post-processing of set scenarios is decoupled from the main data generation process, and can be independently extended to new scenario types, which has strong flexibility and scalability.

[0031] In one possible implementation of the first aspect above, multiple initial sample data are post-processed to obtain multiple target sample data, including: deep processing of the initial sample data and / or the enhanced data after multiple rounds of interaction expansion to obtain the corresponding target sample data. The deep processing includes at least one of scene tag generation, inference process generation, tool execution result generation, and interaction dialogue polishing. The scene tag generation includes: judging the user query statement in at least one of the initial sample data and enhanced data in descending order of priority. If a set scene is hit, the subsequent judgment stops and the corresponding scene tag is generated.

[0032] By deeply processing the generation of scenario tags, inference processes, tool execution results, and interactive dialogue, the dimensions of training data are enriched and the data quality is improved. The scenario tag generation adopts a priority judgment mechanism to ensure that each piece of data obtains a unique and accurate scenario tag, avoiding multiple tag conflicts.

[0033] In one possible implementation of the first aspect above, the reasoning process generation includes: determining whether the scene label is a set scene label, wherein the set scene label includes at least one of a follow-up question scene label, a rejection scene label, and a personal knowledge base scene label; if the scene label is a set scene label, calling the set scene thinking process generation file to generate special reasoning process information containing at least one of follow-up question thinking content, rejection thinking content, or auxiliary tool call thinking content; if the scene label is not a set scene label, calling the general thinking process generation file to generate reasoning process information containing at least one of a task title, task description, trigger description, execution action description, and chain thinking reasoning process.

[0034] By setting up a reasoning process generation mechanism that separates scenarios from general scenarios, we can ensure that the reasoning process content for different scenario types meets the specific interactive logic requirements of that scenario, thereby improving the scenario adaptability and accuracy of the reasoning process information.

[0035] In one possible implementation of the first aspect above, the generation of tool execution results includes: updating the tool registration results and updating the model response information according to the random probability of the triggering conditions and the execution actions.

[0036] By updating the tool registration results and model response information according to random probabilities, the simulation of various outcomes such as tool execution success and failure enhances the task model's ability to handle different tool execution results.

[0037] In one possible implementation of the first aspect mentioned above, the interactive dialogue polishing includes: when the scene tag is a follow-up scene tag or a rejection scene tag, calling the polishing model to polish the model's response and generate standardized interactive dialogue.

[0038] By refining the model's responses for follow-up questions and rejection scenarios, the naturalness and friendliness of the responses are improved, thus enhancing the user experience. This is because the quality of the responses in follow-up questions and rejection scenarios directly affects the user's interaction experience.

[0039] In one possible implementation of the first aspect mentioned above, the trigger-action metadata, initial sample data, and target sample data are all carried using a unified task data structure. The task data structure includes: a basic message field for storing user query statements and model responses; an embedded task tool field, which adopts an embedded decoupled structure and includes mutually independent trigger condition subfields, execution action subfields, logical relationship subfields, and execution frequency subfields, each used to carry corresponding task configuration information; and extended fields, including inference content field, scene label field, tool execution result subfield, and interaction dialogue subfield. The task data structure is compatible with the supervised fine-tuning SFT data format of the OpenAI standard and supports inference-action ReAct capabilities, memory capabilities, graphical user interface (GUI) capabilities, and instruction compliance with multiple system prompts.

[0040] By using a unified task data structure to carry trigger-action metadata, initial sample data, and target sample data, the consistency and scalability of the data structure throughout the entire process are achieved. An embedded decoupled structure is used to carry task configuration information, which is compatible with the standard SFT format while supporting multiple capabilities such as ReAct, memory, and GUI, thereby improving the versatility and scalability of the data structure.

[0041] In one possible implementation of the first aspect above, the inference content field includes: a task title subfield for storing the identifier name of the condition-triggered task; a task description subfield for storing a natural language description of the condition-triggered task; a trigger description subfield for storing natural language description information of the triggering condition; an execution action description subfield for storing natural language description information of the execution action; a follow-up question scenario subfield for storing interactive scenario information that needs to be followed up with the user when the parameters are incomplete; a rejection scenario subfield for storing rejection response information when the triggering condition is not met or the intent cannot be recognized; and a model response subfield for storing standardized response information after task execution.

[0042] By setting subfields such as task title, task description, trigger description, execution action description, follow-up questioning scenario, rejection scenario, and model response in the inference content field, the inference process information can be stored in a structured manner, thereby enhancing the inference ability and interpretability of the task model.

[0043] In one possible implementation of the first aspect mentioned above, the reasoning content field is organized using a chain-like thinking structure, which includes at least one of the following: chain-like reasoning process, task title, task description, trigger description, execution action description, follow-up questioning scenario, rejection scenario, and model response; each subfield of the reasoning content field is decomposed and applied to the task creation, task execution, and user interaction stages respectively.

[0044] By adopting a chain-like thinking structure to organize the reasoning content fields and decomposing each subfield for application in task creation, task execution, and user interaction, the chain-like reasoning capability of the task model is enhanced, thereby improving the model's reasoning accuracy and interpretability in complex task scenarios.

[0045] In one possible implementation of the first aspect mentioned above, in the embedded decoupled structure, the triggering conditions, execution actions, logical relationships, and execution frequencies are configured independently of each other. When adding or modifying the triggering conditions, execution actions, logical relationships, or execution frequencies, the basic framework of the task data structure is not changed.

[0046] By using a decoupled structure where triggering conditions, execution actions, logical relationships, and execution frequencies are configured independently, the basic framework of the task data structure is not changed when adding or modifying any configuration item, thus improving the scalability and maintainability of the data structure.

[0047] In one possible implementation of the first aspect mentioned above, the basic message field of the task data structure adopts a message sequence structure consistent with the standard supervised fine-tuning format, and each message contains a role identifier and message content; the embedded decoupled structure is embedded in the basic message field in the form of extended fields, carrying the configuration information of the condition-triggered task without changing the parsing logic of the standard supervised fine-tuning format.

[0048] By adopting the standard SFT message sequence structure in the basic message fields and embedding the embedded decoupled structure as extended fields, the system carries condition-triggered task configuration information without changing the standard SFT format parsing logic, ensuring the compatibility of the data structure with the existing training framework.

[0049] In one possible implementation of the first aspect mentioned above, the method further includes data backfilling at each stage: in the trigger-action metadata acquisition stage, the trigger condition and the execution action are backfilled into the trigger condition subfield and the execution action subfield, respectively; in the initial sample data generation stage, the user query statement and model response are backfilled into the basic message field, and the tool call example is backfilled into the embedded task tool field; in the post-processing stage, the multi-round interaction logic is backfilled into the message sequence of the basic message field, and the scene label, inference process information, tool execution result and interaction script are backfilled into the scene label field, inference content field, tool execution result subfield and interaction script subfield, respectively.

[0050] Through the data backfilling mechanism at each stage, the integrity and consistency of data are ensured in each stage of trigger-action metadata acquisition, initial sample data generation and post-processing, so as to achieve information traceability and quality assurance throughout the entire data processing process.

[0051] In one possible implementation of the first aspect above, after post-processing multiple initial sample data to obtain multiple target sample data, the method further includes: performing hierarchical verification on the target sample data, wherein the hierarchical verification includes a first-level format verification, a second-level logical consistency verification, and a third-level semantic content verification; wherein the first-level format verification and the second-level logical consistency verification are automated millisecond-level verifications, and the third-level semantic content verification is used to reduce the cost of manual verification; the target sample data that passes the verification is stored in the training dataset, and the target sample data that fails the verification is marked and an anomaly report is output.

[0052] The system employs a layered verification mechanism consisting of a first-layer format verification, a second-layer logical consistency verification, and a third-layer semantic content verification. The first and second layers are automated millisecond-level verifications that quickly filter out format errors and logical contradictions. The third layer reduces the cost of manual verification through semantic understanding. The three layers of verification progressively ensure the quality of training data.

[0053] In one possible implementation of the first aspect above, the method further includes: inputting target sample data into the task model to be trained, performing supervised fine-tuning training on the task model to obtain the trained task model; the task model is used to execute the corresponding condition-triggered task in response to user input that meets the triggering conditions.

[0054] By using validated target sample data for supervised fine-tuning training of the task model, a task model that can accurately understand and execute conditionally triggered tasks is obtained, thereby improving the agent's understanding and execution capabilities in multi-task and multi-conditionally triggered scenarios.

[0055] In a second aspect, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the method as described in any of the first aspects above.

[0056] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any of the first aspects above.

[0057] Fourthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the method described in any of the first aspects above.

[0058] The beneficial effects of the second to fourth aspects mentioned above can be referred to the relevant descriptions in the first aspect and its various possible implementations, which will not be repeated here. Attached Figure Description

[0059] Figure 1A The diagram shown is a schematic of a multi-module cascaded conditional task data generation architecture provided in an embodiment of this application.

[0060] Figure 1B The diagram shown is a user interface schematic of a data generation platform provided in an embodiment of this application.

[0061] Figure 1C The diagram shown is a schematic of the editing task interaction interface of a YOYO agent provided in an embodiment of this application.

[0062] Figure 1D The diagram shown is a schematic representation of a data generation process provided in an embodiment of this application.

[0063] Figure 1E The diagram shown is a flowchart of a model training method provided in an embodiment of this application.

[0064] Figure 2 The diagram shown is a flowchart of a trigger-action metadata construction method provided in an embodiment of this application.

[0065] Figure 3 The diagram shown is a flowchart illustrating a method for determining a scene prompt template and generating a model input prompt according to an embodiment of this application.

[0066] Figure 4 The diagram shown is a flowchart illustrating an initial sample data generation method provided in an embodiment of this application.

[0067] Figure 5 The diagram shown is a flowchart of a post-processing method provided in an embodiment of this application.

[0068] Figure 6 The diagram shown is a flowchart of a multi-round interactive extension method provided in an embodiment of this application.

[0069] Figure 7 The diagram shown is a flowchart illustrating a post-processing method for setting tools provided in an embodiment of this application.

[0070] Figure 8 The diagram shown is a flowchart illustrating a post-processing method for setting a scene, as provided in an embodiment of this application.

[0071] Figure 9 The diagram shown is a flowchart of a deep processing method provided in an embodiment of this application.

[0072] Figure 10 The diagram shown is a schematic diagram of a task data structure provided in an embodiment of this application.

[0073] Figure 11 The diagram shown is a structural schematic of an inference content field provided in an embodiment of this application.

[0074] Figure 12 The diagram shown is a flowchart of a layered verification method provided in an embodiment of this application.

[0075] Figure 13 The diagram shown is a flowchart illustrating a model training method based on target training data provided in an embodiment of this application.

[0076] Figure 14A The image shown is a schematic diagram of a YOYO agent task creation interface provided in an embodiment of this application.

[0077] Figure 14B The image shown is a schematic diagram of a YOYO agent task creation interface provided in an embodiment of this application.

[0078] Figure 14C The image shown is a schematic diagram of a YOYO agent task creation interface provided in an embodiment of this application.

[0079] Figure 14D The image shown is a schematic diagram of a YOYO agent task creation interface provided in an embodiment of this application.

[0080] Figure 14E The image shown is a schematic diagram of a YOYO agent task creation interface provided in an embodiment of this application.

[0081] Figure 14F The image shown is a schematic diagram of a YOYO agent task management interface provided in an embodiment of this application.

[0082] Figure 14GThe diagram shown is a comparative illustration of a YOYO agent task creation interface provided in an embodiment of this application.

[0083] Figure 15 The figure shown is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0084] Figure 16 The diagram shown is a schematic diagram of the operating system software structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0085] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0086] It should also be stated that the steps in the methods and processes in this application are numbered for ease of reference, not to limit the order of steps. If there is an order between the steps, the textual description shall prevail.

[0087] As mentioned earlier, it is currently difficult to construct training data for complex condition-triggered tasks, resulting in insufficient understanding and execution capabilities of intelligent agents in multi-task and multi-condition-triggered scenarios.

[0088] To address this, this application provides a model training method that automates the entire process of generating training data for conditionally triggered tasks through a pipeline of "acquiring trigger-action metadata, determining scene prompt templates and generating model input prompts, calling a large language model to generate initial sample data, and post-processing the initial sample data to obtain target sample data." Specifically, the method first acquires trigger-action metadata containing trigger conditions and execution actions, and acquires scene configuration conditions to provide semantic anchors and constraint boundaries for subsequent data generation; then, it determines multiple scene prompt templates that correspond to the trigger-action metadata and satisfy the scene configuration conditions, fills the scene prompt templates with the trigger-action metadata, and generates multiple model input prompts; next, it calls a large language model to generate multiple initial sample data based on the multiple model input prompts; finally, it post-processes the multiple initial sample data to obtain multiple target sample data for model training.

[0089] Through the above scheme, the final task model can accurately respond to inputs that meet the triggering conditions and reliably execute the corresponding condition-triggered tasks, thereby improving the agent's understanding and execution capabilities in multi-task and multi-condition triggering scenarios.

[0090] It is understandable that an intelligent agent is a main entity with the ability to perceive, reason, invoke tools, remember, and execute; a task model is a core model component deployed and running inside the intelligent agent to handle user tasks.

[0091] After the user inputs their natural language task requirements, these requirements are sent to the agent, which then invokes its internal task model to complete the core logic processing. The task model parses the user's natural language requirements, performing intent recognition, task decomposition, and generating a task workflow. The agent provides the necessary runtime environment for the task model, offering external capabilities such as memory, reasoning acting (ReAct), graphical user interface (GUI) interaction, tool invocation, and system prompt word management. After the task model outputs the task logic and data structure, it is handed over to the agent to invoke various external tools and system capabilities to complete the actual execution of the automated task.

[0092] In some embodiments, the present application can be applied to YOYO task scenarios, allowing users to describe task requirements in natural language, and AI to automatically parse the user's natural language requirements and generate executable automated workflows, especially suitable for appointment-based and condition-triggered task workflows.

[0093] As an example, the business processes involved in the model training method in this application embodiment include, but are not limited to: automatic check-in triggered by geographical location, batch control of cross-brand Internet of Things (IoT) devices, commuting assistant that obtains weather and traffic conditions on a regular basis, health management with timed reminders and data synchronization, bill management that detects bill messages and automatically organizes bills, file organization that automatically completes photo classification and cleaning on a periodic basis, and customer follow-up that monitors message status and automatically follows up with customers.

[0094] For example, in an automated check-in scenario, when the electronic device detects that the geographical location is near a designated location, it automatically jumps to and opens the corresponding check-in page to complete the check-in operation. For example, when the geographical location is near a designated location, the check-in page of the connected component (such as Honor E-link) is opened to check in.

[0095] In IoT device control scenarios, electronic devices can receive user commands and perform control operations on IoT devices of different brands in batches, such as turning off all brands of air conditioners, electric fans and televisions with one click.

[0096] In a commuting assistant scenario, electronic devices can automatically query environmental information and generate travel reminders at preset times. For example, every morning at 7:00, the electronic device automatically obtains the weather and traffic conditions and sets an alarm to remind you to leave.

[0097] In health management scenarios, electronic devices periodically trigger reminders to collect health data and synchronize it. They also send reminder notifications if the user fails to take any action. For example, a reminder might be sent every night at 9 PM to record the user's weight, automatically syncing the data to the health app. If no data is recorded for three consecutive days, a reminder notification is sent.

[0098] In a bill management scenario, when an electronic device detects an incoming bill message, it automatically extracts key bill information from SMS and email, writes it into a financial spreadsheet, and generates a payment reminder. For example, when a credit card bill SMS and email are received, the amount and date are automatically extracted, added to a financial spreadsheet, and a payment reminder is set.

[0099] In file organization scenarios, electronic devices periodically and automatically categorize and clean up local multimedia files. For example, they automatically organize phone photos every Sunday, categorizing them by time and location and deleting duplicate and blurry photos.

[0100] In customer follow-up scenarios, electronic devices monitor the interaction status of communication software. When a customer does not reply to messages for an extended period, the device automatically sends a follow-up message and pushes a contact reminder to the operator. For example, if a customer does not reply to a WeChat message for more than 3 days, the electronic device automatically sends a polite follow-up message and reminds the operator to contact them by phone.

[0101] It is understood that the data acquisition process in the model training method provided in this application embodiment can be adapted to more than ten types of complex business scenarios, support tens of thousands of data requests, and can be extended to more than four hundred tools. Furthermore, this process is compatible with various customized logics such as personal knowledge bases, proactive services, GUI interactions, and alarm clocks, meeting the rapid delivery requirements of monthly iterations with more than ten new sub-requirements added in each iteration.

[0102] The model training method provided in this application is applicable to electronic devices such as terminal devices, servers, or cloud computing platforms with data processing capabilities. For example, such terminal devices include, but are not limited to: cameras, computers, mobile phones, mobile stations (MS), mobile terminals (MT), smart TVs, smart screens, wearable devices, tablets, desktop computers, laptops, virtual reality (VR) devices, augmented reality (AR) devices, terminals in industrial control, self-driving, remote medical surgery, smart grids, transportation safety, smart cities, smart homes, and IoT scenarios. This application does not limit the specific form of the electronic device.

[0103] It is understood that the electronic device executing the model training method and the electronic device deploying and running the trained task model in the embodiments of this application can be either the same electronic device or different independent electronic devices. If they are the same device, model training and model inference interaction are completed locally on that device; if they are different devices, the first electronic device completes the model training, deploys the trained task model to the second electronic device, and the second electronic device runs the task model to drive the agent to complete the user task interaction. For example, the electronic device deploying and running the trained task model can be a terminal device with data processing capabilities, such as a smartphone, tablet, personal digital assistant, or wearable device, or it can be a server or cloud computing platform.

[0104] Reference Figure 1A The diagram illustrates a multi-module cascaded conditional task data generation architecture provided in this application embodiment. The architecture consists of a data planning module, a data generation module, a data deep processing module, and a data verification module, cascaded sequentially, covering the complete training data production chain from task planning, data generation, deep processing to quality verification. This architecture revolves around the design of condition-triggered task data structures, achieving automated and large-scale generation of training data through multi-module collaboration, and ensuring the quality of output data through a hierarchical data verification method.

[0105] The data plan serves as the starting point for the entire data generation process, used to coordinate and configure the dimensions and scale of data generation, including the ratio of single-round tasks to multi-round tasks, the distribution of simple tasks to complex tasks, and the coverage distribution of various tool calls, providing clear generation guidelines and parameter constraints for subsequent data generation modules.

[0106] The data generation module is the core processing unit of this architecture, which is further divided into three sub-parts: basic data generation, specific scenario data (also known as set scenario data) generation, and data post-processing. The basic data generation path follows the process of "selecting tools according to configuration parameters, filling tool parameter slots, and generating questions and answers", automatically generating standardized question and answer samples for tasks triggered by general conditions.

[0107] The specific scenario data generation path targets special scenarios such as GUI scenarios or personal knowledge bases. It simulates real multi-turn dialogues through random rounds of interaction, generating scenario-specific samples containing queries, answers, and tool responses. The raw samples generated by both paths are jointly integrated into the data post-processing submodule. This submodule runs as an independent module, with built-in special processing logic for specific tools and specific scenarios (also known as setting scenarios). For example, for alarm clock tools such as enableAlarm / disableAlarm / deleteAlarm, app usage time query tools, storage space cleaning tools, voice notification tools, communication tools such as call / send_message tools, and geofence tools, customized field completion, parameter validation, and logic correction are performed to ensure the semantic integrity and format standardization of the tool call samples.

[0108] For example, for alarm clock tools, before performing alarm modification or deletion operations, it is necessary to first query the list of existing alarms. Therefore, the post-processing of specific tools will automatically generate alarm-related query information and query results, and insert interactive rounds of calling to query alarms into the dialogue sequence, so that the training data contains the complete interactive logic of "querying the alarm list first, and then performing modification or deletion".

[0109] For example, there are application usage duration query tools, including `app_type_total_usage_time_fence` or `app_type_total_usage_count_fence`. These tools require querying application usage duration statistics. Specific tool post-processing generates query information and results related to the query, ensuring that the data includes the complete call flow and return results for the application usage duration query.

[0110] The storage space cleanup tool (doSpaceCleanInfoByOpList) is unique in that when the opList parameter is empty, the generated user query is prohibited from mentioning cache or memory-related content, as mentioning cache / memory when the opList parameter is empty will result in poor query performance. Therefore, the tool's post-processing handles this tool separately, constraining and correcting the query when the opList parameter is empty to avoid generating query statements that do not meet the actual requirements of the tool's invocation.

[0111] For the voice notification tool (i.e., speak_notice), the generateContent parameter is a required field, and its content is the generated script. The tool's post-processing ensures that this parameter is correctly filled in and verifies that the generated script conforms to the format requirements of voice notifications, preventing tool failures due to missing parameters.

[0112] For communication tools, including calling and sending messages, the parameter constraints are: at least one of the device number (phoneNumber) or message content (contact) must be filled in. When the contact parameter exists, the content name (nameContact) parameter has higher priority than the contact parameter. The post-processing of specific tools will validate these parameter constraints to ensure that at least one contact method is filled in, and when both nameContact and contact parameters exist, the nameContact parameter takes precedence, correcting the parameter filling priority relationship.

[0113] For geofencing tools (i.e., geo_fence), such tools involve querying and parsing address information. Specific tool post-processing will generate address-related query information and query results, such as querying the specific address corresponding to address aliases such as "home" and "company" from a personal knowledge base, to ensure that the training data contains the complete interactive logic of address querying and parsing in geofencing scenarios.

[0114] Understandably, the special processing logic for the six specific tools mentioned above is integrated into an independent module for data post-processing, decoupled from the master data generation process. When a new specific tool needs to be added, only the corresponding tool's special processing logic needs to be added to this independent module, without modifying the master data generation process, demonstrating strong versatility and scalability. Through specific tool post-processing, complex interaction logic requiring auxiliary tools and tool invocation rules with special parameter constraints can be incorporated into the training data, enabling the task model to learn the correct invocation methods and interaction logic for various tools, thereby improving the model's accuracy and robustness in tool invocation in practical applications.

[0115] The samples processed by the data generation module flow into the data deep processing module, which performs two steps in sequence: data deep processing and task type generation. Specifically, data deep processing performs uniform field regularization, deduplication, and format standardization on the samples, while task type generation automatically labels task categories based on the triggering conditions and execution actions of the samples, forming structured training data with task type labels.

[0116] Finally, the training data with task type labels enters the data verification module, which performs multi-level data verification. The module filters and controls the quality of the samples layer by layer from multiple aspects such as format legality, field completeness, logical consistency and semantic rationality, and outputs high-quality training data that meets the SFT standard for use in training the task model.

[0117] In some embodiments, the electronic device performing the model training method in this application may provide a data generation platform (such as DataGen) for uniformly acquiring, managing, and processing the training data of the task model.

[0118] like Figure 1B The diagram shows a user interface of a data generation platform provided in this application embodiment. The user interface 01 of the data generation platform shown on the electronic device 10 includes entry points for functional modules such as dataset management 011, data generation 012, special scenarios 013, independent post-processing 014, data conversion 015, tool data management 016, data verification 017, semantic scoring 018, and model evaluation 019. This covers the entire process of training data processing from acquisition, generation, conversion, verification to model evaluation, providing a standardized source of training data for the model training method in this application. As an example, the electronic device 10 deploying the data generation platform in Figure 1B is shown as a computer.

[0119] In the dataset management module, the data generation platform supports independent management of training and test sets for model training by version, allowing for operations such as creating new versions, renaming, and deleting versions. It supports uploading raw data files in Excel format and automatically converts them to corresponding JSON format training data files; both can be downloaded and deleted. The data list records the upload date, data name, corresponding Excel file, JSON file, and uploader for each dataset, facilitating the tracking of data sources and version iterations. The platform also provides a tool frequency statistics function, which can statistically analyze the distribution of tools and task types based on selected datasets, aiding in the analysis of tool calls and task coverage in the training data, providing a basis for data allocation optimization and model training effect evaluation.

[0120] In the data validation module, the data generation platform provides a visual data validation operation page, supporting the uploading of JSON or JSONL format data files, or the selection of existing validated files, performing basic format validation, and viewing and downloading validation reports online. During validation, users can select action specification files, trigger condition specification files, and external tool specification files as validation benchmarks; the platform defaults to loading the configuration file for the current iteration version. After validation execution, the platform generates historical validation records, recording the execution time, data file name, execution status (e.g., success), and validation results (including pass status and number of error sessions) for each validation task. It supports online viewing of validation details and downloading of validation reports, facilitating the tracking of the data quality iteration process.

[0121] Through the aforementioned data generation platform, user natural language commands, multi-turn dialogue contexts, and confirmed structured task results collected during intelligent agent interaction can be uniformly imported into the dataset management module. After being processed by the data conversion module into training samples compatible with the SFT standard format, and then after quality screening by modules such as data verification and semantic scoring, the data is output as training data (i.e., sample data) for the task model, supporting the execution of the model training method.

[0122] It is understandable that the aforementioned multi-module cascaded conditional task data generation architecture corresponds to and carries over the various functional modules in the data generation platform. For example, each processing module in the architecture is specifically implemented by the corresponding functional module in the data generation platform, which further expands its data management, semantic evaluation, and model validation capabilities based on the architecture.

[0123] As an example, the data plan corresponds to the dataset management module and tool data management module in the data generation platform. The dataset management module manages the training set and test set independently by version, supports creating new versions, renaming, deleting versions, and uploading and downloading files, and carries the configuration of data version and training set / test set division in the data plan; the tool data management module provides statistical functions for tool distribution and task type distribution, and carries the planning and allocation constraints of tool call coverage distribution in the data plan.

[0124] The data generation module corresponds to the data generation module, special scenario module, and independent post-processing module in the data generation platform. The platform's data generation module carries the basic data generation path of the architecture, executing a general sample generation process of "selecting tools based on configuration parameters, filling tool parameter slots, and generating queries and answers." The special scenario module carries the specific scenario data (i.e., set scenario data) generation path of the architecture, generating scenario-specific multi-round samples through random rounds of interaction for special scenarios such as GUI scenarios and personal knowledge bases. The independent post-processing module carries the data post-processing sub-module of the architecture, running independently to perform customized field completion and logic correction for specific tools such as alarm clocks, application queries, storage cleanup, voice notifications, communications, and geofencing.

[0125] The data deep processing module corresponds to the data conversion module in the data generation platform. The data conversion module performs format conversion, field normalization, deduplication, and standardization processing on the raw data in Excel format to the training data in JSON format. Based on trigger conditions and execution actions, it also completes automatic labeling of task types, carrying out the two-step operations of data deep processing and task type generation in the architecture.

[0126] The data validation module corresponds to the data validation module in the data generation platform. The data validation module performs multi-level validation on the samples from aspects such as format validity, field integrity, and logical consistency, carrying out the quality screening function of multi-level data validation in the architecture.

[0127] In addition, the data generation platform also includes a semantic scoring module and a model evaluation module. These two modules extend the quality enhancement capabilities beyond the aforementioned data generation architecture. The semantic scoring module scores and filters the semantic rationality of the generated samples, further improving the quality of the training data. The model evaluation module uses the generated training data to evaluate the training effect of the task model, verifying the effectiveness of the data generation strategy, thus forming a closed loop of "data generation, model training, effect feedback, and data optimization".

[0128] In some embodiments, the data generation platform also provides a workflow progress visualization function, organizing the data management and data verification processes into a visualization tool to generate data plan schedules and data verification reports. The workflow is cascaded sequentially according to the following order: data planning, statistical distribution of data indicators, pre-generation of large models, manual annotation, in-depth data processing, data verification, model business (including pre-training, supervised fine-tuning and evaluation), and delivery. Each workflow node is marked with its execution status (including completion, pass, and failure). It supports three progress advancement methods: automatic progress synchronization, progress synchronization after verification, and manual mark reset, realizing full-process visualized management of training data from planning, generation, verification to model training and delivery.

[0129] Reference Figure 1C This application provides an interactive interface for editing tasks in a YOYO agent, as illustrated in an embodiment of the present application. The task model trained using the model training method described in this embodiment is deployed within the YOYO agent and executed by the agent. Figure 1C The task creation and multi-round modification interaction process is shown below. As an example, Figure 1C The electronic device 20 that deploys and runs the trained task model is shown as a mobile phone, that is, the YOYO agent containing the task model is deployed in the mobile phone.

[0130] like Figure 1C As shown in the interactive interface 21 for editing tasks, the user inputs the original task requirement via natural language: "Read me the day's weather forecast and schedule every morning." After receiving this natural language requirement, the agent parses and generates a preliminary automated task. It further interacts with the user to confirm the triggering conditions, and completes the task planning based on the user's supplementary instruction, "Play it when the alarm is turned off every morning." A "Weather and Schedule Broadcast" task card is generated, recording the task name, triggering conditions, and execution actions. The user is prompted to manually modify the task via voice or by clicking the card. Subsequently, the user inputs the modification instruction again, "Change to immediate execution, and also broadcast unread text messages." The agent responds to the modification instruction, updates the task configuration, and obtains the modified "Weather and Schedule Broadcast" task. At this point, the updated task adjusts the triggering condition to support immediate execution, and updates the execution action to play the weather forecast and unread text messages every day when the alarm is turned off, completing the iterative modification of the task. Furthermore, Figure 1C The interface shown has a voice input control at the bottom that allows users to continuously input task creation or modification commands via voice.

[0131] In addition, in the above Figure 1CDuring the interaction process shown, the agent collects the user's original task statement, user-supplemented correction instructions, multi-turn dialogue context, and the final structured task data confirmed by the user. This part of the interaction sample can be fed back to the training data generation stage of model training in this embodiment. At this time, these interaction samples are converted into data samples compatible with the SFT standard, which are used to iteratively optimize the task model, forming a closed loop of model training, agent interaction, sample feedback, and model iteration.

[0132] Understandably, the current field of conditional task generation lacks a universal data generation method. For example, YOYO tasks involve numerous scenarios, hundreds of integrated tools, and complex multi-round interaction logic. Manual annotation suffers from slow production speed and high rework rates. Existing data generation chains exhibit poor scalability and scenario adaptability. Furthermore, solutions based on simultaneous query-toolcall generation are difficult to modify and prone to errors. Therefore, the model training method provided in this application offers a step-by-step conditional task data generation approach.

[0133] Reference Figure 1D This diagram illustrates a data generation process provided in an embodiment of this application. This data generation process can be executed by the data generation module described above. Specifically, the process includes the following four steps: S1, generating seed data for trigger conditions and actions; S2, generating raw data (also known as raw queries) according to a scenario; S3, post-processing for specific tools / scenarios; and S4, outputting basic data. Specifically, step S1 generates seed data containing trigger conditions and execution actions, including toolcall truth values ​​(toolcall-gt), as the basic anchor point for subsequent generation; step S2 generates raw data containing queries and answers based on the seed data according to a scenario; step S3 performs customized post-processing for specific tools (also known as setting tools) and specific scenarios (also known as setting scenarios), completing the query results and customizing the interaction logic; finally, step S4 outputs standardized basic data. This basic data can then be processed in subsequent steps such as further processing.

[0134] As an example, Figure 1DThe data generation process shown can be implemented through code engineering. For example, the file architecture related to the data generation process provided in this application embodiment includes code files 1 to 10. Specifically, code file 1 (main.py) serves as the general data generation entry point, supporting single-round and multi-round trigger-action generation. Code files 2 (personal_knowledge_base_data_gen.py) and 3 (gui_task_create_data_gen.py) are responsible for specific data generation for personal knowledge base scenarios and GUI scenarios, respectively. Code file 4 (tool_catalog.py) is responsible for tool JSON loading, prompt assembly and parameter sampling, validation, and type casting. Code files 5 (fill_special_tool_columns.py), 6 (fill_think_column.py), and 7 (fill_task_type_column) respectively perform post-processing of specific tool fields, generation of the thinking process (think) column, and annotation of the task type column. Code file 8 (llm_client.py) is used to encapsulate the large language model gateway call. The code file 9 (prompts) directory is divided into general prompts for various scenarios, thought process prompts, and tool-specific prompts (such as alarm clocks and calls). The code file 10 (tool_data) directory stores tool definitions and mock data. These files work together to support the automated execution of the four-step data generation process.

[0135] Reference Figure 1E This is a flowchart illustrating a model training method provided in an embodiment of this application. The method can be applied to an electronic device 10, which can be a terminal device with data processing capabilities such as a smartphone, tablet, personal digital assistant, or wearable device, or it can be a server or cloud computing platform. The method includes the following steps:

[0136] S101, obtain trigger-action metadata and scene configuration conditions.

[0137] Among them, trigger-action metadata (also known as trigger, action seed data, or seed data) refers to structured data containing paired combinations of triggering conditions and execution actions, used as semantic anchors and ground truth (gt) for subsequent data generation. Triggering conditions (such as trigger descriptions) describe the conditions under which the task is triggered, such as "at 8 a.m. tomorrow", "near home", "when Bluetooth is turned on", etc.; execution actions describe the specific operations that need to be performed after the task is triggered, such as "play song 2 by artist 1", "turn on Bluetooth", "remind me to eat", etc.

[0138] Scene configuration conditions (such as a scene configuration table) are used to constrain the scope of scenes and interaction rules for data generation, including scene descriptions, a list of available tools, and interaction constraints. Scene descriptions define the semantic boundaries of the target scene; the list of available tools limits the range of tools that can be invoked within that scene; and interaction constraints specify the dialogue interaction rules for that scene, such as whether multi-turn interactions are allowed or whether follow-up questions are required.

[0139] S102, identify multiple scene prompt templates that correspond to the trigger-action metadata and meet the scene configuration conditions, and fill the trigger-action metadata into the multiple scene prompt templates to generate multiple model input prompts.

[0140] Scene prompt templates (such as scene prompt words) are predefined templates used to guide large language models (LLMs) in generating dialogue data for specific scenes. For example, scene prompt templates are stored in two ways: prompt words and skills, supporting flexible addition and deletion. The prompt-based templates are prompt word texts that can be directly used as input to the LLM; the skill-based templates are skill descriptions that can be invoked by the agent system, including skill name, skill description, input / output format, etc. Both storage methods support flexible addition and deletion, facilitating the rapid expansion of new scene types.

[0141] Understandably, the scenario prompt templates are stored using both prompt and skill methods. This supports both prompt text that can be directly used as input for large language models and skill descriptions that can be called by the Agent system, making them compatible with different data generation and system integration scenarios. The templates support flexible addition and deletion, allowing for rapid expansion of new scenario types or decommissioning of no longer needed scenarios during business iterations without modifying the main data generation process, significantly improving the system's scalability and maintenance efficiency.

[0142] Each scene prompt template includes elements such as tone word configuration, sentence template, and character description, which are used to guide the large language model to generate dialogue data that conforms to the style and interaction characteristics of the target scene.

[0143] In some embodiments, model input prompts (such as large language model input generated by filling trigger-action metadata with scene prompt words) are complete large language model inputs obtained by filling trigger-action metadata into scene prompt templates.

[0144] In some embodiments, when determining scene prompt templates, the electronic device first determines the target scene category based on the triggering conditions and execution actions in the trigger-action metadata. Then, it retrieves the scene configuration conditions corresponding to the target scene category from a preset scene configuration library. Finally, based on a preset scene generation ratio, it dynamically selects multiple scene prompt templates that meet the scene configuration conditions from the scene configuration library. The scene generation ratio is used to control the distribution of different scene types in the generated data; for example, simple scenes account for 30%, follow-up questions account for 20%, and rejection scenarios account for 15%.

[0145] In some embodiments, when generating model input prompts, the electronic device uses the triggering conditions and execution actions from the trigger-action metadata as slot values ​​and fills them into the corresponding slots of each scene prompt template to generate multiple model input prompts. Each model input prompt corresponds to a scene prompt template and a set of trigger-action metadata.

[0146] S103, call the large language model and obtain multiple initial sample data generated by the large language model based on multiple model input prompts.

[0147] Large language models refer to language models that have been pre-trained on a large scale and are capable of understanding and generating natural language text. Initial sample data (also known as raw data / raw query) is the raw dialogue data generated by the large language model based on model input prompts, including user query statements, model responses, and tool call examples.

[0148] In some embodiments, electronic devices can call different large language model interfaces in parallel to generate data for different scenario prompt templates, thereby improving generation efficiency and enhancing the generalization of user query statements.

[0149] As an example, when generating initial sample data, the method of generating user query statements from the standard answer (i.e., gt→query reverse generation) is adopted. Based on the triggering conditions and execution actions in the trigger-action metadata, the large language model generates user query statements corresponding to the standard answer.

[0150] S104 involves post-processing multiple initial sample data to obtain multiple target sample data, which are then used for model training.

[0151] In some embodiments, post-processing refers to a series of processing operations that enhance, update (i.e., refresh) and further process the initial sample data, including sub-processes such as multi-round interactive expansion, tool-specific post-processing, scenario-specific post-processing, and further processing (executed by the data deep processing module). Target sample data (also known as target data) is high-quality training data obtained after post-processing, containing rich scene labels, inference process information, tool execution results, and interactive dialogue, which can be directly used for supervised fine-tuning training of the task model.

[0152] Understandably, each initial sample data undergoes multiple rounds of interactive expansion, post-processing with specific tools, and post-processing for specific scenarios to obtain basic data (such as...). Figure 1D The basic data shown is then further processed to obtain the target sample data. In other words, the above-mentioned deep processing is performed on the basic data after multiple rounds of interactive expansion, post-processing with specific tools, and post-processing in specific scenarios.

[0153] Thus, the model training method provided in this application, through a multi-module cascaded data generation pipeline, achieves fully automated generation of training data for condition-triggered tasks. This enables data production efficiency of up to 300 data entries per 10 minutes with a pass rate of over 90%, and supports rapid expansion to over 400 triggering conditions and execution actions.

[0154] Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for constructing trigger-action metadata (i.e., trigger and action seed data) according to an embodiment of this application. In step S101 above, obtaining the trigger-action metadata can be achieved through the following sub-steps:

[0155] S201, obtain the tool definition and tool common scenario slot mapping table.

[0156] The tool definition includes a tool identifier, a tool description, and a parameter list. The tool identifier is used to uniquely identify a tool, such as "music_player", "alarm", "Bluetooth", etc.; the tool description describes the function and purpose of the tool; and the parameter list defines the parameters that need to be passed in when the tool is called, as well as their types and value ranges.

[0157] The tool common scenario slot mapping table includes at least one common scenario for each tool and its slot value template. Common scenarios refer to the scenario types that the tool is frequently used in actual business. For example, common scenarios for a music playback tool include "timed playback" and "playing at a specified location," which can be selected or set according to the user's actual needs. Slot value templates are used to define the typical values ​​or value ranges of each parameter in the scenario. For example, the slot template for playback time can be "tomorrow {time} o'clock," and the slot template for song name can be "{song} of {artist}".

[0158] S202, iterate through each tool in the tool definition, and match the common scenarios corresponding to each tool according to the tool common scenario slot mapping table.

[0159] In this embodiment, all tools in the tool definition are traversed one by one. For each tool, all common scenarios corresponding to that tool are looked up in the tool common scenario slot mapping table. A tool can correspond to multiple common scenarios. For example, an alarm clock tool can correspond to multiple common scenarios such as "single alarm", "repeated alarm", and "alarm deletion".

[0160] S203. For each common scenario that is matched, the slot is instantiated according to the slot value template to obtain the corresponding parameter value.

[0161] In this embodiment, for each tool-common scenario combination, parameters are instantiated based on the slot value template. Slot instantiation can be achieved through random value selection, enumeration, or sampling based on real data. For example, for the "timed music playback" scenario, the time slot can be randomly selected from the range of "6:00-23:00", the singer slot can be randomly selected from a preset singer list, and the song slot can be randomly selected from the singer's popular song list.

[0162] S204 generates trigger conditions based on scene description and instantiated parameter values, and generates execution actions based on tool identifier and instantiated parameter values. The trigger conditions and execution actions are paired and combined to obtain trigger-action metadata.

[0163] In this embodiment, the trigger condition is generated based on the scene description and the instantiated parameter values. For example, if the scene description is "timed playback" and the instantiated parameters are "tomorrow at 8 o'clock", "singer 1", and "song 2", then the generated trigger condition is "tomorrow at 8 o'clock". The execution action is generated based on the tool identifier and the instantiated parameter values. For example, if the tool identifier is "music_player" and the instantiated parameters are "singer 1" and "song 2", then the generated execution action is "play song 2 by singer 1".

[0164] It is understood that the embodiments of this application pair and combine the generated triggering conditions and execution actions to obtain a trigger-action metadata record. By traversing all tools and common scenarios and performing multiple slot instantiations, a large number of trigger-action metadata records can be generated in batches, providing sufficient semantic anchors for subsequent data generation.

[0165] Thus, in this embodiment, through the automatic matching mechanism of tool definition and common scenario slot mapping table, the batch and automated generation of trigger conditions and execution actions are achieved, eliminating the need for manual task configuration design and significantly improving the production efficiency of seed data. Furthermore, slot instantiation supports multiple methods such as random value selection, enumeration value selection, and sampling based on real data, enhancing the diversity and scenario coverage of seed data. The pairing and combination of trigger conditions and execution actions form structured metadata, providing stable semantic anchors and standard answers for subsequent data generation, effectively reducing the risk of illusions in the subsequent generation process of large language models.

[0166] In some embodiments, Figure 2 The steps shown for generating seed data (i.e., trigger-action metadata) for trigger conditions and execution actions can be divided into two generation paths: general scenarios and special scenarios.

[0167] As an example, the general scenario path takes tool definitions and a common scenario slot mapping table as input, and outputs seed data for matching trigger conditions and execution actions, such as pairing the time fence "tomorrow at 8 o'clock" with playing music "Singer 1 + Song 2". This general scenario path supports flexible configuration such as specifying tools (for specific scenario supplementation), specifying not to select a tool (for excluding non-general tools), random range selection (for batch adding tools), setting the number of trigger conditions and execution actions (for logical relationship scenarios), and setting the trigger frequency (for customized periodic scenarios). It also supports generating data based on the priority of key slots in common scenarios. For example, for the music playback tool, P0-level slots such as person, content, and app, P1-level slots such as source and comment, and P2-level slots such as contentType and openApp are generated in a priority ratio of 6:3:1.

[0168] As an example, the special scenario path takes a fixed-range tool definition, an external knowledge base (such as a personal knowledge base), and an interaction logic template (a customized .md file) as input, and outputs trigger conditions and seed data for specific slots. For example, the relationship "mother" is paired with the geofence "arrive at the company" and the music playback "singer 1 + song 2". This path supports complex slot filling by dynamically loading interaction templates for different scenarios and dynamically reading external knowledge bases. Since special scenarios generally have higher requirements for data quantity and quality, decoupling allows for individual optimization for each scenario.

[0169] In some embodiments, the trigger-action metadata, i.e., seed data generation in this application, achieves fine-grained control over the generation process through a set of flexibly configurable parameters, covering multiple dimensions such as generation scale, path configuration, model selection, tool selection, task complexity, execution results, and reproducibility. Regarding generation scale, the number of independent dialogues generated at one time (e.g., 10) is configured through the `num_dialogues` configuration item, and the number of rounds of dialogue generation (e.g., 1 round) is configured through the `num_turns` configuration item, achieving precise control over the amount of generated data. Regarding path configuration, the directory containing scene prompts is specified through the `scenario_path` configuration item, the definition file paths of the trigger condition tool and the execution action tool are specified through the `trigger_path` and `action_path` configuration items, respectively, and the output path of the generated data is specified through the `output_path` configuration item, ensuring that the input and output paths of each stage of data generation are clear and configurable. Regarding model selection, the large language model used for generation (e.g., GPT-4O) is configured through the `model` parameter, allowing for flexible switching based on data quality requirements and cost considerations.

[0170] Regarding tool selection, the options trigger_tool_names and action_tool_names allow you to explicitly specify which tools to use. The option random_*_anchor_per_dialogue controls whether to randomly add tools. The option allowed_random_tools sets the whitelist of tools for random addition (None means that all tools are available and the entire dialogue must contain at least one anchor tool; it does not require that each round has a tool from the pool). The option exclude_random_tools sets the tools that will never be selected during random addition, thus enabling fine-grained control over tool selection. Regarding task complexity, the range of trigger conditions and actions per dialogue (e.g., 1 to 2) can be configured through the configuration options random_triggers_per_dialogue and random_actions_per_dialogue, respectively. The quota ratio of execution frequency can be configured through the configuration option repeat_ratio (e.g., 0.2:0.2:0.6 for each time, single time, and empty time). The ratio of logical AND / OR between multiple trigger conditions can be configured through the configuration option multi_trigger_logic_or_ratio, thereby enabling controllable adjustment of the task complexity and scene distribution of the generated data.

[0171] Furthermore, the probability of the tool's execution result being a successful JSON is configured via the `execution_result_success_ratio` option, ensuring that the training data includes a certain proportion of execution failure scenarios and improving the model's ability to handle anomalies. The `random_seed` option sets a random seed to ensure reproducible generation results, and the `generate_max_workers` option configures the number of concurrent threads to improve generation efficiency. These configuration parameters work together to support the scalable, controllable, and reproducible execution of trigger conditions and execution action seed data generation, providing a stable, diverse, and high-quality semantic anchor foundation for subsequent generation of original query statements and data post-processing based on specific scenarios.

[0172] Please see Figure 3 , Figure 3 This is a flowchart illustrating a method for determining a scene prompt template (i.e., scene prompt words) and generating model input prompts, provided in an embodiment of this application. In step S102 above, determining the scene prompt template and generating model input prompts can be achieved through the following sub-steps:

[0173] S301, determine the target scenario category based on the triggering conditions and execution actions in the trigger-action metadata.

[0174] In some embodiments, the target scenario category refers to the type of dialogue scenario that the trigger-action metadata is suitable for generating. The electronic device can determine the target scenario category based on factors such as the complexity of the triggering conditions, the number of actions performed, and whether parameter completion is required. For example, when the triggering condition is a single time condition and the action performed is a single operation, the target scenario category can be determined as a "simple scenario"; when the triggering condition contains multiple conditions and there is a logical AND / OR relationship, the target scenario category can be determined as a "logical AND / OR scenario"; when the action performed contains multiple operations, the target scenario category can be determined as a "multi-action scenario".

[0175] S302, retrieve the scene configuration conditions corresponding to the target scene category from the preset scene configuration library.

[0176] The scenario configuration library is a predefined database that stores configuration information for each scenario category. Each scenario category corresponds to a set of scenario configuration conditions (such as a scenario configuration table), including a scenario description, a list of available tools, and interaction constraints. The scenario description defines the semantic boundaries and typical features of the scenario; the list of available tools limits the range of tools that can be called in the scenario; and the interaction constraints specify the dialogue interaction rules in the scenario, such as whether multi-turn interaction is allowed, whether follow-up questions are required, and whether rejection is allowed.

[0177] S303: Based on the preset scene generation ratio, dynamically select multiple scene prompt templates that meet the scene configuration conditions from the scene configuration library.

[0178] The scene generation ratio is a preset configuration of the proportion of each scene type in the generated data, used to control the scene distribution of the generated data. For example, it can be configured as follows: simple scenes 30%, logical AND / OR scenes 10%, multi-action scenes 10%, follow-up questions 15%, rejection scenes 10%, independent multi-task scenes 10%, multi-round modification scenes 10%, and multi-round addition scenes 5%. Based on the scene generation ratio, a corresponding number of scene prompt templates can be dynamically selected to ensure that the scene distribution of the generated data meets business requirements.

[0179] Scene prompt templates (i.e. scene prompt words) are templates used to guide large language models to generate dialogue data for specific scenes.

[0180] S304. The triggering conditions and execution actions in the trigger-action metadata are used as slot values ​​and filled into the corresponding slots of each scene prompt template to generate multiple model input prompts.

[0181] In this embodiment, each scene prompt template contains several predefined slots, such as {trigger condition}, {action}, {time}, {location}, {item}, etc. The trigger condition and action from the trigger-action metadata are used as slot values ​​and filled into the corresponding slots to generate a complete model input prompt (i.e., the large language model input generated after scene prompt words fill the trigger-action metadata). For each trigger-action metadata, multiple different scene prompt templates can be filled to generate multiple different model input prompts, thereby achieving diversified data generation.

[0182] In some embodiments, the scene prompt template includes tone word configuration, sentence structure template, and character description. The tone word configuration defines the tone style of the generated dialogue, such as "friendly and natural," "concise and clear," or "lively and cute." The sentence structure template defines the grammatical structure and expression of the generated sentences, such as declarative sentences, interrogative sentences, or imperative sentences. The character description defines the role of the assistant in the dialogue, such as "intelligent assistant YOYO" or "thoughtful life manager." These configurations guide the large language model to generate dialogue data that conforms to the style and interaction characteristics of the target scene.

[0183] Understandably, by configuring interjections, sentence templates, and character descriptions, the dialogue style generated by the large language model can be refined to ensure that the generated user queries conform to the language style and interaction characteristics of the target scenario, thereby improving the realism and scenario adaptability of the data. By automatically filling the scenario prompt template with triggering conditions and execution actions as slot values, the automatic splicing of task configuration and scenario template is achieved. The generated model input prompts contain clear task semantic anchors and incorporate scenario-based expression guidance, which is conducive to the large language model generating high-quality and diverse dialogue data.

[0184] Thus, in this embodiment, the scope of the generated scenarios and the interaction rules are precisely constrained through three-dimensional configuration: scenario description, list of available tools, and interaction constraints, ensuring that the generated data conforms to the semantic boundaries of the target scenario. Furthermore, the target scenario category is automatically determined based on trigger-action metadata, achieving intelligent matching between task configuration and scenario type; scenario prompt templates are dynamically selected according to a preset scenario generation ratio, precisely controlling the distribution ratio of different scenario types in the generated data, meeting the business's requirements for the proportion of data for various scenarios, and avoiding model bias caused by too much or too little data for a certain type of scenario.

[0185] Please see Figure 4 , Figure 4This is a flowchart illustrating a method for generating initial sample data (i.e., raw data / raw query) according to an embodiment of this application. In step S103 above, generating initial sample data by calling a large language model can be achieved through the following sub-steps:

[0186] S401 generates data by calling different large language model interfaces in parallel for different scenario prompt templates.

[0187] In some embodiments, to improve data generation efficiency and enhance the generalization of user queries, different large language model interfaces can be called in parallel for data generation based on different scenario prompt templates. For example, model A can be called for simple scenario templates, model B can be called for follow-up question scenario templates, and model C can be called for rejection scenario templates. Different large language models differ in language style, expression habits, and reasoning ability. By calling multiple models in parallel, more diverse user queries can be generated, enhancing the generalization of training data.

[0188] Understandably, calling different large language model interfaces in parallel for different scenario prompt templates can significantly shorten the total time for batch data generation and improve data production efficiency through parallel processing. On the other hand, different large language models have differences in language style, expression habits and reasoning ability. Generating by mixing multiple models can increase the diversity of user query expression, enhance the generalization of training data, and avoid the risk of model overfitting caused by a single model generating a style that is too uniform.

[0189] S402 adopts the method of generating user query statements from the standard answer. Based on the triggering conditions and execution actions in the trigger-action metadata, the large language model generates user query statements corresponding to the standard answer.

[0190] In this embodiment, a GT→Query reverse generation approach is adopted. This involves first providing a standard answer (triggering conditions + execution actions), and then using a large language model to reverse-generate the natural language query statements that the user might use. The core idea of ​​this approach is: given a defined task configuration (when to trigger, what actions to execute), the large language model simulates various natural language expressions that the user might use to describe the task requirements.

[0191] For example, the standard answer is "Trigger condition: 8 o'clock tomorrow; Action: Play singer 1's song 2". The large language model can generate various user query statements in reverse: "YOYO, please play singer 1's song 2 for me at 8 o'clock tomorrow", "Remind me to listen to song 2 at 8 o'clock tomorrow morning", "Set an alarm for 8 o'clock tomorrow, and play singer 1's song at that time", etc.

[0192] Understandably, compared to the traditional method of forward generation of user query statements using tool calls (Query→GT), the reverse generation method has the following advantages: First, the standard answer is structured and deterministic, and the large language model only needs to focus on the diversity of user expressions without simultaneously reasoning about tool call logic, thus significantly reducing model illusion; Second, the generated user query statements naturally correspond to the standard answer, eliminating the need for additional alignment checks; Third, it can generate multiple user query statements with different expressions for the same standard answer, improving data diversity and generalization.

[0193] S403: Obtain user query statements, model responses, and tool call examples generated by the large language model to form initial sample data.

[0194] In some embodiments, the output generated by the large language model based on model input prompts includes a user query, a model response, and a tool call example. The user query is a natural language expression that the user might use; the model response is the assistant's response to the user query; and the tool call example is the tool that the assistant needs to call and its parameters, corresponding to the execution action in the trigger-action metadata.

[0195] The scenario type corresponding to the initial sample data (i.e., raw data / raw query) includes at least one of the following:

[0196] (1) Simple scenario: single trigger condition + single execution action, such as "play song 2 for me at 8 o'clock tomorrow".

[0197] (2) Logical AND / OR scenario: There is a logical AND / OR relationship between multiple triggering conditions, such as "Tomorrow at 8 o'clock and when Bluetooth is on, play a song for me 2".

[0198] (3) Multiple execution actions scenario: One trigger condition corresponds to multiple execution actions, such as "Tomorrow at 8 o'clock, play a song 2 by singer 1 for me, then turn on Bluetooth and remind me to eat".

[0199] (4) Follow-up question scenario: The user's query statement is missing necessary parameters, and the assistant needs to ask for supplementation, such as "Play that music for me at 8 o'clock tomorrow" (missing song name, needs to be asked for supplementation).

[0200] (5) Rejection scenario: The user's query does not meet the requirements of the condition-triggered task, and the assistant needs to reject it. For example, "Play a song 2 by singer 1" (there is no triggering condition, so it does not belong to the condition-triggered task).

[0201] (6) Independent multi-task scenario: The user query contains multiple independent condition-triggered tasks, such as "Tomorrow at 8 o'clock, please select a song for me, and then turn off the music playback at 9 o'clock".

[0202] (7) Multi-round modification scenario: After creating a task in the first round, the user modifies the task parameters in the second round. For example, Q1: "Play a song 2 by singer 1 for me at 8 o'clock tomorrow", Q2: "Change it to 9 o'clock".

[0203] (8) Multiple rounds of new scenarios: After the user creates a task in the first round, the user adds new task content in the second round, such as Q1: "Play a song 2 by singer 1 for me at 8 o'clock tomorrow", Q2: "Remind me to eat breakfast by the way".

[0204] Understandably, the initial sample data includes three dimensions: user queries, model responses, and tool call examples, forming a complete dialogue interaction sample that can comprehensively train the task model's understanding, response, and tool call capabilities. The initial sample data covers eight scenario types: simple scenarios, logical AND / OR scenarios, multi-action scenarios, follow-up questioning scenarios, rejection scenarios, independent multi-task scenarios, multi-round modification scenarios, and multi-round addition scenarios. This ensures that the training data fully covers various typical interaction patterns of conditionally triggered tasks, improving the task model's generalization ability and robustness in complex multi-scenario environments.

[0205] In other words, this embodiment uses the seed data of generated triggering conditions and execution actions as semantic anchors, combined with inputs such as scene configuration tables, scene prompts, tone word and sentence structure personification configurations, and model selection, to generate raw sample data containing user query statements, model responses, and tool call examples from a large language model. Specifically, the raw sample data generation process adopts the GT→Query reverse generation method, which reverse-generates the user's natural language expression based on the standard answer, significantly reducing model illusions compared to forward generation. The output raw sample data covers the above eight scene types, providing a raw data foundation for subsequent data post-processing and in-depth processing.

[0206] It is important to note that the aforementioned multi-round modification scenarios and multi-round addition scenarios belong to the raw data generation stage, and are scenario types directly generated by the large language model based on scenario prompt templates. This differs from the "multi-round interactive extension" mechanism in the post-processing stage. Multi-round interactive extension is an enhancement mechanism in the post-processing stage that supplements single-round initial sample data with multi-round interactive logic.

[0207] Thus, in this embodiment, the initial sample data can comprehensively train the task model's understanding, response, and tool invocation capabilities, and covers multiple scenario types, ensuring that the training data fully covers various typical interaction modes of conditionally triggered tasks. This improves the task model's generalization ability and robustness in complex, multi-scenario environments.

[0208] Please see Figure 5 and Figure 6 , Figure 5 This is a flowchart illustrating a post-processing method provided in an embodiment of this application. Figure 6 This is a flowchart illustrating a multi-round interactive expansion method provided in an embodiment of this application. In step S104 above, post-processing of the initial sample data first includes multi-round interactive expansion, which can be specifically achieved through... Figure 5 The following sub-steps are implemented as shown:

[0209] S501 parses the initial sample data to extract tool call information and scene feature information.

[0210] In this embodiment, each initial sample data is structured and parsed to extract tool call information (including the tool identifier, parameter list, parameter values, etc.) and scene feature information (including scene type, trigger condition complexity, number of actions executed, whether parameter completion is required, etc.).

[0211] S502, match the tool call information with the preset tool set, and match the scene feature information with the preset scene category.

[0212] The preset toolset refers to a set of tools that require special post-processing, such as alarm clock tools and tools for creating viral app scenarios that require auxiliary tools. The preset scenario category refers to a category of scenarios that require special post-processing, such as complex multi-branch scenarios like personal knowledge base scenarios, address list selection scenarios, and workflow modification scenarios.

[0213] S503: The initial sample data that has been successfully matched is identified as the data to be enhanced. The data to be enhanced is extended through multiple rounds of interaction to generate multi-round interaction logic that includes at least one of the following rounds: confirmation round, parameter inquiry round, modification round, and result feedback round, so as to obtain the enhanced data.

[0214] In this embodiment, the initially matched sample data (i.e., data requiring special post-processing) is identified as data to be enhanced (i.e., intermediate state data requiring multiple rounds of interactive expansion in the post-processing flow), and then undergoes multiple rounds of interactive expansion. Multi-round interactive expansion refers to an enhancement mechanism in the post-processing stage that supplements single-round initial sample data with multiple rounds of interactive logic, distinct from the multi-round modification and multi-round addition scenarios in the original data generation stage (see details). Figure 4 (Related instructions in the document).

[0215] Multi-turn interaction extensions may include at least one of the following turn types:

[0216] (1) Confirm the round: Before executing the task, the assistant confirms the task configuration with the user, such as "Do you want to set a reminder to play song 2 at 8 o'clock tomorrow?".

[0217] (2) Parameter follow-up rounds: When the user's query statement is missing necessary parameters, the assistant will ask the user to supplement them, such as "Which song would you like to play?".

[0218] (3) Modify the round: The user can modify the task parameters during the conversation, such as "Change it to 9 o'clock tomorrow".

[0219] (4) Result feedback rounds: After the assistant performs the task, it will provide feedback to the user on the execution result, such as "A reminder has been set for you to play song 2 at 8 o'clock tomorrow".

[0220] Thus, in this embodiment, by performing structured parsing on the initial sample data, tool call information and scene feature information are automatically extracted and matched with a preset tool set and scene category, enabling automatic filtering and location of data requiring special processing without manual judgment of each item. The successfully matched data is identified as data to be enhanced and multi-round interactive expansion is performed, automatically supplementing interactive logic such as confirmation rounds, parameter follow-up rounds, modification rounds, and result feedback rounds, so that the training data contains richer multi-round interactive content, improving the ability of the task model to handle complex multi-round dialogue scenarios, while avoiding the high cost and low efficiency of manually writing multi-round dialogues.

[0221] Please see Figure 6 The multi-round interactive extension process can be implemented through the following sub-steps:

[0222] S601, based on the triggering conditions and execution actions in the data to be enhanced, determine the type of interaction rounds that need to be supplemented.

[0223] In some embodiments, the electronic device analyzes which types of interaction rounds need to be added based on the specific content of the data to be enhanced. For example, if the triggering condition includes address information and the address may not be unique, then parameter follow-up rounds need to be added; if the action involves deletion, then confirmation rounds need to be added; if the scenario type is a multi-round modification scenario, then modification rounds need to be added.

[0224] S602, select the corresponding scene template from the preset scene template library according to the interaction round type.

[0225] The scene template library stores scene templates corresponding to various interaction rounds. Scene templates are stored in prompt and skill formats, and can be added or deleted. Based on the determined interaction round type, the corresponding scene template is selected from the scene template library to guide the large language model in generating the dialogue content for that round.

[0226] S603 generates supplementary interaction round data based on the context information in the scene template and the data to be enhanced.

[0227] In this embodiment, contextual information (including user query statements, triggering conditions, and execution actions) from the data to be enhanced is filled into the scene template, and a large language model is invoked to generate supplementary interaction round data. The generated supplementary round data needs to maintain contextual coherence and logical consistency with the original data.

[0228] S604. The supplementary interaction round data is concatenated with the data to be enhanced to obtain enhanced data containing multi-round interaction logic.

[0229] In some embodiments, the electronic device can concatenate the generated supplementary interaction rounds data with the original data to be enhanced, according to the chronological order of the dialogue, to form a complete multi-turn dialogue sequence, which is the enhanced data (i.e., intermediate state data expanded through multiple rounds of interaction). The enhanced data contains richer interaction logic, which can better train the task model to handle complex multi-turn interaction scenarios.

[0230] Thus, the multi-turn interaction expansion in this embodiment adopts a standardized four-step process: "determining the turn type, selecting a scene template, generating supplementary turns, and splicing to obtain enhanced data," achieving automated and reproducible generation of multi-turn interaction logic. Furthermore, the required supplementary interaction turn type is intelligently determined based on the specific content of the data to be enhanced, ensuring that the expanded interaction logic matches the task configuration of the original data. Scene templates are stored in prompt and skill formats and support addition and deletion, allowing for rapid expansion of new interaction turn types. In addition, the generated supplementary turn data is spliced ​​with the original data in chronological order to form a complete, context-coherent multi-turn dialogue sequence, ensuring logical consistency of the data.

[0231] Please see Figure 7 , Figure 7 This is a flowchart illustrating a specific tool post-processing method provided in an embodiment of this application. After obtaining enhanced data through the aforementioned multi-round interactive expansion, for enhanced data that requires the assistance of auxiliary tools, specific tool post-processing is also required. Specific tool post-processing refers to updating the enhanced data for tasks that require the assistance of auxiliary tools (such as alarm clock tools, app best-seller scenario tools, etc.) to ensure that the generated data conforms to the calling requirements and interaction logic of the specific tool. Specific tools include, but are not limited to, the following two categories:

[0232] (1) Alarm clock tool: This involves operations such as deleting and modifying alarm clocks. You need to first query the existing list of alarm clocks and then perform the deletion or modification operation.

[0233] (2) App popular scenario tools: These involve typical operation scenarios of popular apps. They require calling an external app knowledge base to obtain app description information and generating query information based on the app description information.

[0234] Post-processing for specific tools can be achieved through the following sub-steps:

[0235] S701 calls an external knowledge base to obtain the tool description information corresponding to the auxiliary tool.

[0236] In this embodiment, for augmented data that requires the assistance of tools, the tool description information corresponding to the tool is first obtained by calling an external knowledge base. The external knowledge base may include an app knowledge base, a tool registry, etc., storing information such as the function description, parameter definitions, calling methods, and return result formats of each tool. For tools involving reasoning based on app description information and with a long context (such as tools for app bestseller scenarios), complete tool description information needs to be obtained from the external knowledge base.

[0237] S702, inference is performed based on the tool description information to generate query information.

[0238] In this embodiment, based on the acquired tool description information and task configuration in the enhanced data, logical reasoning is performed to generate query information that needs to be sent to the auxiliary tool. For example, for the alarm clock deletion task, query information "query all current alarm clocks" needs to be generated; for the app popularity scenario task, query information "query the app's popular functions and typical uses" needs to be generated.

[0239] S703, Execute the query based on the query information and obtain the query results.

[0240] In this embodiment, the generated query information is sent to the corresponding auxiliary tool or external system to execute the query operation and obtain the returned query results. The query results can be structured data (such as an alarm clock list, an app function list, etc.) or natural language descriptions. The query results need to conform to the return format requirements of the auxiliary tool.

[0241] S704 updates the augmented data based on the query information and query results, so that the updated data conforms to the format requirements of the auxiliary tool.

[0242] In this embodiment, query information and results are integrated into the dialogue sequence of enhanced data to update the enhanced data. Specifically, auxiliary tool call rounds are inserted into the dialogue sequence of enhanced data, including the assistant initiating a query, the auxiliary tool returning results, and the assistant continuing processing based on the results. The updated data needs to conform to the call format requirements of the auxiliary tool, including the parameter format of the tool call, the parsing method of the returned results, and subsequent interaction logic.

[0243] As an example, the post-processing of specific tools in this application performs customized field completion and parameter correction for five typical tools. For example, (1) for app query related tools, randomly select app types, extract 3 to 10 application lists and 50 to 100 query samples from the application information database, rewrite the query placeholders, and write the query information, query results, application type and application list in the trigger conditions, user query statement and model reply and task type (app query) into the corresponding fields. (2) for alarm clock tools, call the big language model to generate alarm clock query data, and write the query information, query results, alarm clock identifier list in the execution action and task type (alarm clock) into the corresponding fields. (3) for reminder tools, call the big language model to supplement the generated content parameters, and write the completed parameters into the JSON parameter field of the execution action. (4) for calling and sending text messages tools, perform contact disambiguation (distinguish between name contacts and number contacts) and number name generalization, and write the corrected parameters into the JSON parameter field of the execution action. (5) For space cleaning tools, the parameter type is type-casted and the converted parameters are written into the JSON field of the execution action. Through the customized post-processing of the above five types of tools, it is ensured that the generated training data meets the actual calling format requirements and parameter constraints of each tool, thereby improving the semantic integrity and format standardization of the tool calling samples.

[0244] The following example, using an alarm clock deletion tool, illustrates the specific post-processing steps of such a tool:

[0245] Suppose the original augmented data content is "User: Delete the alarm clock for 8 AM tomorrow". After post-processing and updating using a specific tool, the dialogue sequence becomes:

[0246] User: Delete the alarm for 8 AM tomorrow;

[0247] Assistant: Invoke the alarm clock query tool [Query Information];

[0248] Tool returns: Current alarm list: Tomorrow at 7 AM alarm, Tomorrow at 8 AM music alarm [Query Results];

[0249] Assistant: Your music alarm for 8 AM tomorrow has been removed.

[0250] The following example, using tools for creating viral apps, illustrates the specific post-processing steps of a particular tool:

[0251] Suppose the original content of the augmented data is "User: Order me a milk tea using XX app". After post-processing and updating with a specific tool, the dialogue sequence becomes:

[0252] User: Order me a milk tea using the XX app;

[0253] Assistant: Query the description information of XX app from an external app knowledge base [Query Information];

[0254] Tool return: XXapp supports functions such as food delivery ordering, product search, and order inquiry. To place an order, you need to specify the product name, specifications, and delivery address. [Search Results]

[0255] Assistant: Which milk tea would you like to order? What size do you need? What is your shipping address?

[0256] Thus, this embodiment of the application, through specific tool post-processing, can integrate complex interaction logic that requires the assistance of auxiliary tools into the training data, enabling the task model to learn the calling method and interaction logic of the auxiliary tools, thereby improving the model's tool calling capability in practical applications. The specific tool post-processing adopts a fixed step-by-step process, decoupled from the main data generation process, and will not affect the main process, thus possessing strong versatility.

[0257] Please see Figure 8 , Figure 8 This is a flowchart illustrating a specific scenario post-processing method provided in an embodiment of this application. After obtaining enhanced data through the aforementioned multi-turn interaction expansion, enhanced data that hits a specific scenario (i.e., a defined scenario) still needs to undergo specific scenario post-processing. Specific scenario post-processing refers to processing highly complex scenarios (such as address list selection scenarios, workflow modification scenarios, personal knowledge base scenarios, etc.) that contain multiple sub-scenario branches and complex multi-turn interaction logic. Large language models cannot easily generate complete and accurate dialogue data in one step, requiring updates by scenario branch through an independent post-processing process. Specifically, this can be achieved through the following sub-steps:

[0258] S801, identify the specific scenario type corresponding to the augmented data, the specific scenario type includes at least one of the following: personal knowledge base scenario, address list selection scenario, and workflow modification scenario.

[0259] In this embodiment, based on the triggering conditions, execution actions, and scene feature information in the enhanced data, it is identified whether the data matches a specific scene type. Specific scene types include, but are not limited to:

[0260] (1) Personal knowledge base scenario: The task involves querying and using the user's personal knowledge base, such as a scenario where the geofence trigger condition includes "home" or "company" and requires parsing the specific address from the personal knowledge base.

[0261] (2) Address list selection scenario: The task involves the display of an address list and user selection. For example, in scenarios such as navigation and geofencing, users need to select the target address from multiple address candidates.

[0262] (3) Modify workflow scenario: The task involves modifying the created automated workflow, such as modifying the trigger conditions, modifying the execution actions, adding / deleting task steps, etc.

[0263] S802, invokes the scene post-processing template corresponding to the specific scene type.

[0264] In this embodiment, each specific scene type corresponds to a predefined scene post-processing template. The scene post-processing template defines the interaction flow, branching logic, data update rules, etc., for that scene. The scene post-processing template can be stored as a Markdown file, supporting flexible modification and expansion. Based on the identified specific scene type, the corresponding scene post-processing template is invoked for data updates.

[0265] S803 updates the augmented data according to the preset scene branch ratio, generating training data that includes complex rounds of interaction and multiple branches of sub-scenes.

[0266] In this embodiment, a specific scenario typically includes multiple sub-scenario branches, with different branches corresponding to different interaction logic. For example, an address query in a personal knowledge base scenario may include the following branches:

[0267] (1) Address query is empty: There is no matching address in the personal knowledge base, and the user needs to be guided to add an address.

[0268] (2) Unique address lookup: There is only one matching address in the personal knowledge base, and the address can be used directly.

[0269] (3) Multiple address queries: There are multiple matching addresses in the personal knowledge base, and a list of addresses needs to be displayed for users to choose from.

[0270] (4) Query error: If an error occurs during the personal knowledge base query, the user needs to be prompted to retry or manually enter the information.

[0271] Different scenario branches correspond to different orchestration and interaction logic. Based on the preset scenario branch ratio (e.g., 10% for empty address queries, 30% for unique addresses, 50% for multiple addresses, and 10% for abnormal addresses), a scenario branch is randomly selected, and the augmented data is updated according to the interaction logic of that branch to generate training data containing complex rounds of interaction and multiple branches of sub-scenes.

[0272] The following example, using a personal knowledge base scenario, illustrates the specific post-processing process in a particular scenario:

[0273] Assume the original trigger-action metadata is: trigger condition = geofence (address: home, action: arrive), and action = turn on Bluetooth.

[0274] Step 1: Identify that the address "home" matches the personal knowledge base scenario and call the personal knowledge base scenario post-processing template.

[0275] Step 2: Randomly select the scenario branch and query rounds. Assume that the "address query is multiple" branch is selected, and the query rounds are 3.

[0276] Step 3: Simulate the personal knowledge base query process to generate query information and results. For example, the query results may include three address candidates: Address A, Nanjing Xinjiekou, and Address C.

[0277] Step 4: Update the dialogue sequence based on the query results. The updated dialogue sequence is as follows:

[0278] Q1: When you get home, please turn on Bluetooth for me;

[0279] A1: Access personal knowledge base to query (home address) [Query Information];

[0280] T1: Returns three address candidates: address A, address B, and address C [Query Results];

[0281] A2: Multiple matching addresses were detected. Please select your home address: 1. Address A 2. Address B 3. Address C;

[0282] Q2: The second one;

[0283] A3: Trigger condition = geofence (address: address B, action: arrive), action = turn on Bluetooth;

[0284] It should be noted that the above example simulates three rounds and the address query has multiple branches. If two rounds are simulated and the address query has a single branch, it is not necessary to return multiple address candidates; the unique address found can be used directly to update the triggering condition. If more rounds are simulated, follow-up questions can be continuously added, such as simulating abnormal interaction branches when the user does not answer as required, to enhance the coverage of training data on complex interaction scenarios.

[0285] Step 5: Update and overwrite the original data, and label the scene as "Personal Knowledge Base Scene" to complete the post-processing for the specific scene.

[0286] Furthermore, it's necessary to distinguish between the different mechanisms of tool-specific post-processing and scenario-specific post-processing: tool-specific post-processing typically involves a fixed round of special tool invocation, such as deleting an alarm clock always requiring a round of alarm clock query; while scenario-specific post-processing includes multiple random branches and multiple rounds of interaction, with different branches corresponding to different orchestration and interaction logic. The two operate decoupled, do not affect each other, and together constitute a complete post-processing system.

[0287] Thus, this embodiment of the application, through specific scenario post-processing, can generate complex multi-turn interaction data and sub-scenario multi-branch data that are difficult for large language models to generate in one step, significantly improving the coverage and quality of training data in complex scenarios. Specific scenario post-processing is decoupled from the main data generation process, allowing for independent expansion to new scenario types, demonstrating strong flexibility and scalability.

[0288] Please see Figure 9 , Figure 9 This is a flowchart illustrating a deep processing (i.e., data deep processing module) method provided in an embodiment of this application. In the above post-processing flow, in addition to multi-round interactive expansion, specific tool post-processing, and specific scenario post-processing, deep processing is also included. Specifically, the above deep processing can be implemented through the following sub-steps:

[0289] S901: Identify the initial sample data and / or the enhanced data after multiple rounds of interactive expansion as data to be further processed.

[0290] S902: Perform further processing on the data to be processed to obtain the corresponding target sample data.

[0291] Deep processing refers to further enriching and standardizing the data to generate high-quality training data that includes scene labels, inference process information, tool execution results, and interactive dialogue.

[0292] As an example, the data deep processing module includes four sub-modules: scene tag generation (i.e., tag generation path), reasoning process generation (i.e., thinking process generation path), tool execution result generation (i.e., tool execution result generation path), and interactive dialogue polishing (i.e., follow-up questioning / refusal dialogue polishing).

[0293] As an example, the input for deep processing is basic data (JSON or Excel format files) obtained after multiple rounds of interactive expansion, post-processing with specific tools, and post-processing with specific scenarios. This basic data has problems such as missing thought processes, fixed tool execution results, and poor generalization of model responses and follow-up / rejection dialogues. The output of deep processing is high-quality training data that includes complex thought processes, random tool execution results (including successful execution and execution failure with reasons for failure), intelligent follow-up dialogues, rejection dialogues, response dialogues, and task type labels.

[0294] (a) Scene tag generation.

[0295] Scene tag generation refers to labeling each data entry with its corresponding scene category (i.e., tag), which is used for subsequent data validation, data analysis (distribution statistics, summarization), and in-depth data processing. Scene tag generation adopts a priority judgment mechanism: in user queries from at least one of the initial sample data and augmented data, the tags are judged in descending order of priority. If a specific scene is matched, the subsequent judgment stops, and the corresponding scene tag is generated.

[0296] For example, the priority from high to low can be configured as follows: Personal knowledge base scenario > Rejection scenario > Follow-up question scenario > Multi-round modification scenario > Multi-round addition scenario > Independent multi-task scenario > Multi-action scenario > Logical AND / OR scenario > Simple scenario. For each piece of data, the user query is checked according to the above priority to see if it matches the characteristics of that scenario. Once a scenario is matched, it is labeled with that scenario and subsequent judgments are terminated. This priority judgment mechanism can ensure that each piece of data obtains a unique and accurate scenario label, avoiding multiple label conflicts.

[0297] As an example, task type tag generation combines code-based hard judgment with large language model judgment, executing sequentially from high to low priority, stopping once a match is found. Specific judgment rules are divided into four priorities: Priority 1 uses code-based hard judgment, identifying based on query field features, including: Personal knowledge base scenario (if the user's query contains the `momery_fast_search_contain_dialog` field, it's determined to be a personal knowledge base scenario, affecting the entire conversation); Alarm clock scenario (if the queryAlarm tool is called, it's determined to be an alarm clock scenario, affecting the entire conversation); Modify task title scenario (if the modify_workflow_title tool is called, it's determined to be a task title modification scenario, affecting the entire conversation); Application (app) query scenario (if the user's query contains the `app_type` or `app_list` field, it's determined to be an app query scenario, affecting the entire conversation). Priority 2 uses a hard-coded judgment method, identifying tasks based on dialogue round characteristics, including: single-round tasks (a single-round task is defined as one dialogue round with the number of tool calls matching the single-round characteristic, affecting only one line); multi-round tasks (multi-round interactions involving asks and queries are defined as multi-round tasks, affecting the entire dialogue); and multi-round corrections (refocusing triggering conditions or actions, affecting only one line). Priority 3 uses a large language model judgment method, identifying tasks through semantic understanding, including: multi-round corrections (modifying triggering conditions or actions in subsequent queries on the same task, affecting the entire dialogue); and multi-round single tasks (integrating unrelated independent tasks in a multi-round dialogue, affecting the entire dialogue). Priority 4 is a fallback judgment, classifying data that does not match priorities 1 to 3 as the default scenario type. By combining the above-mentioned hard code judgment with the large language model judgment, a four-level priority judgment mechanism can be implemented to achieve automated and accurate labeling of task type labels, ensuring that each piece of data obtains a unique and accurate scene label and avoiding multiple label conflicts.

[0298] (ii) Generation of reasoning process.

[0299] Reasoning process generation refers to generating reasoning content (i.e., reasoning_content) for each piece of data, containing task reasoning information, to enhance the reasoning ability and interpretability of the task model. Reasoning process generation employs a scenario-based distribution mechanism:

[0300] First, determine whether the scene tag is a specific scene tag (also known as a set scene tag). Specific scene tags include at least one of the following: follow-up question scene tag, rejection scene tag, and personal knowledge base scene tag.

[0301] If the scenario label is a specific scenario label, a specific scenario-specific thinking process generation file (e.g., the query_prerequisite_thinking.md file) is invoked to generate special reasoning process information. This special reasoning process information varies depending on the scenario type: for follow-up question scenarios, follow-up question thinking content is generated, describing how the assistant determines missing parameters and organizes follow-up questioning; for rejection scenarios, rejection thinking content is generated, describing how the assistant determines that the user's intent does not meet the conditions for triggering the task and organizes a rejection response; for auxiliary tool scenarios (such as personal knowledge base, query alarm clock, etc.), thinking content for calling auxiliary tools is generated, describing how the assistant determines that auxiliary tools need to be called and organizes the tool call logic.

[0302] If the scene tag is not a specific scene tag, the generic thinking process generation file (e.g., the thinking_generation.md file) is invoked to generate generic reasoning process information. This generic reasoning process information includes at least one of the following: task title, task description, trigger description, action description, and chain of thought (COT) reasoning process. Specifically, the task title is used for displaying the title during the task creation phase and the capsule during the execution phase; the task description is used for displaying the description during the task creation phase; the trigger description is used for displaying the details of the trigger conditions on the editing page; the action description is used for displaying the details of the action performed on the editing page; and the chain of thought reasoning process describes the complete reasoning chain from the assistant understanding the user's intent to generating the tool call.

[0303] It is understood that the reasoning process generation in this embodiment adopts a scenario-based flow mechanism. For specific scenario tags such as follow-up questioning, rejection, and personal knowledge base, specific scenario-based thinking process generation files are called to generate special reasoning process information containing follow-up questioning content, rejection thinking content, or thinking content called by auxiliary tools. For general scenarios, general thinking process generation files are called to generate general reasoning process information containing task title, task description, trigger description, execution action description, and chain-like reasoning process. This flow mechanism ensures that the reasoning process for a specific scenario conforms to the specific interaction logic of that scenario, while also ensuring the standardization and consistency of the reasoning process for general scenarios. The generated reasoning process information enhances the reasoning ability and interpretability of the task model. The subfields of the reasoning content fields can be decomposed and applied to multiple stages such as task creation, task execution, and user interaction, improving the efficiency of information reuse.

[0304] (iii) Generation of tool execution results.

[0305] Tool execution result generation refers to simulating the tool execution process for each data point and generating tool execution results, which are used to train the task model's ability to process tool execution results. Tool execution result generation adopts a random probability mechanism: according to the random probability of triggering conditions and execution actions, the tool registration results are updated, and the model response information (i.e., summary information) is updated.

[0306] Specifically, for each tool call in the data, the tool execution result is randomly generated according to a preset probability distribution, including success and failure (with reasons for failure). For example, the success rate can be configured to be 80% and the failure rate to be 20%, and the failure reasons can be randomly selected from a preset list of failure reasons (such as "tool not registered," "invalid parameters," "network timeout," "insufficient permissions," etc.). Based on the generated tool execution results, the model's response information is updated synchronously to ensure consistency between the model's response and the tool execution results. By randomly generating tool execution results, the diversity of tool execution results in the training data can be enriched, improving the task model's ability to handle various tool execution results in practical applications. This, in turn, enhances the task model's ability and robustness in handling various tool execution results in real-world applications.

[0307] (iv) Polishing the interactive dialogue.

[0308] Interactive dialogue polishing refers to optimizing the dialogue of a model's response in a specific scenario to improve its naturalness and friendliness. Interactive dialogue polishing employs a scenario-triggered mechanism: when the scenario tag is a follow-up question tag or a rejection tag, the polishing model is invoked to refine the model's response, generating standardized interactive dialogue.

[0309] It should be noted that the deep processing logic is integrated into specific business logic, allowing for customization of thought processes, simulation tool execution results, and refinement of model wording. It is decoupled from the master data generation process, can be dynamically selected for integration, and can be expanded with new customized data logic. Because data comes from multiple sources (including Alibaba™, test, beta™, open source, etc.), this type of data requires deep processing before it can be reasonably integrated into YOYO tasks. Therefore, the deep processing module is a key link in achieving multi-source data fusion and standardization.

[0310] In scenarios involving follow-up questions and rejection, the quality of the model's response dialogue is crucial, directly impacting user experience. By utilizing a specialized polishing model, the original model's response can be optimized to be more natural, friendly, and consistent with the user's established persona. The polishing model can rewrite and optimize responses based on preset dialogue style guidelines (such as friendly tone, concise expression, and avoiding harshness). For model responses in non-follow-up questioning and non-rejection scenarios, since the dialogue requirements are relatively lower, specialized polishing can be omitted to improve processing efficiency.

[0311] Thus, this application embodiment enriches the data through in-depth processing across four dimensions: scene tags, inference process, tool execution results, and interactive dialogue. Furthermore, scene tags are prioritized and interrupted upon a match, ensuring unique and accurate tags and avoiding multi-tag conflicts.

[0312] In some embodiments, this application provides a reasoning process generation mechanism that employs a scenario-based flow splitting approach. The thought process content differs between general scenarios and special scenarios. The specific implementation process is as follows: First, the configuration JSON (containing tool and scenario configurations) is read, each sample is traversed, and the sample scenario type is distinguished. For the tool verification (valtool) template group scenario, the user query statement and execution action are read, the query statement and execution action are adjusted to include existing skip / modify tools, and then, based on the configuration input of the triggering conditions and execution actions, the execution result is modified to a failure response. For the question record scenario, the model response and assistant interaction content are read, the large language model is called to complete the reasoning process, and new reasoning content containing the original model response is output. During the reasoning content generation process, it is determined whether it is a personal knowledge base scenario based on the tools involved in the user query statement: if it is a personal knowledge base scenario, a dedicated personal prompt word template is called to generate special reasoning process information; if it is a non-personal knowledge base scenario, a hard-coded general reasoning process template is used. The reasoning process for general scenarios includes a task title, task description, trigger condition description, action description, and chain-of-action (COT) thinking process. In specific scenarios, follow-up questions require generating "ask" thinking content, rejection scenarios require generating "refuse" thinking content, and auxiliary tool scenarios (such as personal knowledge bases or alarm clock queries) require generating thinking content for invoking these tools. This scenario-based diversion and differentiated generation mechanism ensures that the reasoning process content in different scenarios conforms to the specific interactive logic requirements of that scenario, improving the scenario adaptability and accuracy of the reasoning process information.

[0313] In some embodiments, the reasoning content for different scenario types is generated using different templates, and its internal structure and tagging system differ. As an example, the reasoning content for general scenarios is generated using a unified template, including a task title, task description, trigger condition description, action description, and chain-thinking (COT) reasoning process. For instance, for a user query "Turn on WiFi when I reach address A," the reasoning content would be: "The user wants to create a geolocation-triggered task: automatically turn on WiFi when arriving at the specific location address A. This is a typical 'arrival-and-execute' scenario, requiring accurate geofencing identification and triggering network settings changes." <title> Arrive at address A and turn on WiFi< / title> <desc> WiFi will automatically turn on upon arrival at No. 23 Nanchang Road.< / desc><trigger> Condition 1: Arrival address A< / trigger> <action> Task 1: Turn on WiFi< / action> ".

[0314] The reasoning process content for special scenarios uses differentiated templates based on the scenario subtype: the follow-up question scenario generation includes follow-up question scenario tags ( <ask>The reasoning process, for example, when a user queries "When I exit that app, turn on dark mode for me," involves determining that the current query does not provide the specific app name, which is essential information for executing the task, and then... <ask> Could you tell me which specific app requires dark mode to be enabled when exiting?< / ask> Tag organization for follow-up questioning techniques; generation of refusal-to-identify scenarios including tags for refusal-to-identify scenarios ( <refuse>The reasoning process involves considering factors such as: For example, regarding a user query "Automatically open NetEase Cloud Music when I exercise," a detailed analysis of the reasoning process reveals that both the triggering conditions (the inability to reliably identify the dynamic state of "exercise") and the execution action (deep integration with third-party music applications without openness) are subject to unsolvable constraints. <refuse> If the trigger condition is not supported, inform the user that the task cannot be created.< / refuse> Tag rejection conclusions; summary scenario generation including summary tags ( <summary>The thought process, after all tasks are completed, is passed through... <summary> Summarize all execution results for the user< / summary> The tag aggregation tool executes the results and generates a summary response visible to the user. For auxiliary tool scenarios (such as personal knowledge bases, alarm clock queries, etc.), it generates reasoning content to invoke these tools. For example, in the personal knowledge base scenario, the reasoning process is "It is necessary to query the user's home address to determine the specific geographical location," triggering the `_text_search_contain_dialog` tool to query the home address. In the alarm clock scenario, the reasoning process is "First, query the corresponding alarm clock to obtain its alarm ID," triggering the `queryAlarm` tool to obtain the alarm identifier. This differentiated template mechanism ensures that the reasoning process content for different scenario types conforms to the specific interaction logic and tag specifications of that scenario.

[0315] Please see Figure 10 and Figure 11 , Figure 10 This is a schematic diagram of a task data structure (i.e., a condition-triggered task data structure) provided in an embodiment of this application. Figure 11 This is a schematic diagram of the structure of a reasoning content field (i.e., reasoning_content) provided in an embodiment of this application.

[0316] In this embodiment, the trigger-action metadata, initial sample data, and target sample data are all carried using a unified task data structure to achieve consistency and scalability of the entire data structure. This task data structure is compatible with the OpenAI standard's SFT data format and supports multiple trigger conditions and multiple execution actions (i.e., multiple triggers + actions), React (Reasoning + Acting) capabilities, proactive service capabilities, Skill loading, external knowledge injection, replanning capabilities, GUI (Graphical User Interface) capabilities, and instruction compliance with multiple system prompts, exhibiting strong scalability without changing the basic data structure.

[0317] The task data structure includes the following fields:

[0318] (a) Basic message fields.

[0319] The basic message field stores user queries and model responses, employing a message sequence structure consistent with the standard supervised fine-tuning format. Each message contains a role identifier and message content. Role identifiers can be "user," "assistant," "system," "tool," etc. The message sequence structure of the basic message field inherently supports carrying multi-turn interaction data; multi-turn interaction logic can be implemented by appending multi-turn dialogue messages to the message sequence.

[0320] (ii) Embedded task tool field.

[0321] The embedded task tool field (i.e., embedded structure / task tool) adopts an embedded decoupled structure, including mutually independent trigger condition subfields (i.e., trigger), execution action subfields (i.e., action), logical relationship subfields (i.e., logic), and execution frequency subfields (i.e., repeat), which are used to carry the corresponding task configuration information.

[0322] The trigger condition subfield is used to arrange the trigger conditions for tasks, such as time conditions ("Tomorrow at 8 o'clock"), geofence conditions ("Arrived at home"), status conditions ("Bluetooth is on"), etc.

[0323] The "Execution Action" subfield is used to orchestrate the execution actions of a task, such as "Play music", "Turn on Bluetooth", "Send reminder", etc.

[0324] The logical relation subfield is used to represent the logical relationship between multiple triggering conditions, such as "AND" or "OR". When multiple triggering conditions exist, the logical combination logic between the conditions is defined through the logical relation subfield.

[0325] The execution frequency subfield is used to indicate the frequency of task execution, such as "single", "daily repetition", "weekly repetition", "custom cycle", etc.

[0326] The four sub-fields described above are configured independently and decoupled, ensuring they do not affect each other. Adding or modifying trigger conditions, actions, logical relationships, or execution frequencies does not alter the basic framework of the task data structure; only the content of the corresponding sub-field needs to be modified. This embedded decoupling structure effectively prevents mutual interference between different task configuration items, improving the maintainability and scalability of the data structure.

[0327] The embedded decoupled structure is embedded in the basic message fields as extended fields, carrying configuration information for conditionally triggered tasks without changing the standard supervised fine-tuning format parsing logic. This means that existing SFT data parsing frameworks can directly parse the data structure of this task without modifying the parsing logic, thus achieving seamless compatibility with the existing ecosystem.

[0328] (iii) Extended fields

[0329] The extended fields include the reasoning content field, the scene tag field, the tool execution result subfield, and the interaction script subfield.

[0330] It should be noted that the tool execution result subfield and the interaction script subfield are used to structurally encapsulate the tool execution results and interaction scripts output by the deep processing module. They are a field-based encapsulation of the deep processing output content. For example, as the output content of deep processing, the tool execution results and interaction scripts are elevated to independent subfields under extended fields in this embodiment for easier structured management.

[0331] Thus, in this embodiment of the application, the trigger-action metadata, initial sample data, and target sample data are all carried by a unified task data structure, which achieves consistency of the data structure throughout the process and avoids information loss and compatibility issues caused by data format conversion.

[0332] In some embodiments, the reasoning_content field is used to store information about the reasoning process and is organized using a chain-of-thinking (COT) structure.

[0333] Please see Figure 11 The reasoning content field includes the following subfields:

[0334] (1) Task title subfield (i.e. title): used to store the identifier name of the condition-triggered task, and used for the title display during the task creation stage and the capsule display during the execution stage.

[0335] (2) Task description subfield (i.e., desc): used to store the natural language description of the condition-triggered task, and used for the description display during the task creation stage.

[0336] (3) Trigger description subfield (i.e., trigger): used to store natural language description information of the trigger conditions, and used to display the details of the trigger conditions on the editing page.

[0337] (4) Action description subfield (i.e., action): Used to store natural language description information of the action to be executed, and used to display the details of the action to be executed on the editing page.

[0338] (5) Follow-up scenario subfield (i.e., ask): Used to store interactive scenario information that needs to be asked by the user when the parameters are incomplete, and is used to specify the reasoning and response logic in the follow-up scenario.

[0339] (6) Refuse scenario subfield: used to store the rejection response information when the triggering condition is not met or the intent cannot be recognized, and to specify the reasoning and response logic in the rejection scenario.

[0340] (7) Model response subfield (i.e. summary): used to store standardized response information after task execution, representing the final response content of the model.

[0341] The subfields of the inference content field can be broken down and applied separately to the three stages of task creation, task execution, and user interaction. For example, the task title and task description are applied to the task creation stage; the trigger description and action description are applied to the task editing and execution stages; and the follow-up questioning scenario, rejection scenario, and model response are applied to the user interaction stage. Through this decomposition and application, the same inference content information can play a role in different stages of the task lifecycle, improving the efficiency of information reuse.

[0342] The scene tag field (tag) is used to store scene tags, which indicate the scene category to which the current data belongs. These tags are used for subsequent data validation, data analysis (distribution statistics, summarization), and in-depth data processing.

[0343] The tool execution result subfield is used to store the tool execution result, including the tool execution success / failure status, failure reason, returned data, etc.

[0344] The Interaction Script subfield is used to store polished, standardized interaction scripts, especially optimized responses for follow-up questions and rejection scenarios.

[0345] (iv) Data backfilling mechanism at each stage.

[0346] At each stage of data generation, the corresponding data needs to be backfilled into the corresponding fields of the task data structure to achieve consistency of the data structure throughout the entire process.

[0347] (1) During the trigger-action metadata acquisition stage, the trigger condition and the execution action are backfilled into the trigger condition subfield and the execution action subfield, respectively.

[0348] (2) During the initial sample data generation stage, user query statements and model responses are backfilled into the basic message field, and tool call examples are backfilled into the embedded task tool field.

[0349] (3) In the post-processing stage, the multi-round interaction logic is backfilled into the message sequence of the basic message field, and the scene label, reasoning process information, tool execution result and interaction script are backfilled into the scene label field, reasoning content field, tool execution result subfield and interaction script subfield respectively.

[0350] Through the data backfilling mechanism at each stage, it is ensured that the data is always carried by a unified task data structure throughout the entire process from trigger-action metadata to initial sample data and then to target sample data, thus avoiding information loss and compatibility issues caused by data format conversion.

[0351] Understandably, the inference content field is subdivided into seven subfields: task title, task description, trigger description, execution action description, follow-up questioning scenario, rejection scenario, and model response. This fine-grained field design allows for precise location and flexible use of inference content information. Each subfield can be broken down and applied to different stages of the task lifecycle, improving information reuse efficiency and system maintainability.

[0352] Please see Figure 12 , Figure 12 This is a flowchart illustrating a hierarchical verification (i.e., hierarchical data verification method) provided in an embodiment of this application. After obtaining the target sample data through the above post-processing, hierarchical verification can be performed on the target sample data to ensure the quality of the training data.

[0353] Specifically, the above-mentioned layered verification process includes the following steps:

[0354] S1201: Perform the first layer of validation on the target sample data.

[0355] Reference Figure 12 The diagram shown is a schematic representation of the layered verification process provided in this application embodiment. The layered verification includes a three-layer verification mechanism: a first-layer format verification, a second-layer logical consistency verification, and a third-layer semantic content verification.

[0356] Specifically, the first layer of validation is format validation, used to check whether the format of the target sample data conforms to preset specifications. Specific checks include: whether the data is in valid JSON format; whether all required fields are present (such as basic message fields, embedded task tool fields, etc.); whether the field types are correct (e.g., trigger condition subfields should be string types, logical relationship subfields should be enumeration types, etc.); and whether field values ​​are within the legal range (e.g., execution frequency subfields should be within the range of "single / daily / weekly / custom"). Format validation is automated, with processing speeds down to milliseconds, quickly filtering out data with incorrect formats.

[0357] In addition, the first-level format verification is a code-level verification. It performs verification by matching the preset data structure template (scheme template). It has the characteristics of strong versatility and fast response. It can batch process and repair data with basic format mismatch. It is especially suitable for the basic format mismatch problem that is common in external multi-source data (including data from Alibaba, open source, manually constructed, third-party and other sources).

[0358] S1202: Perform a second-level verification on the target sample data that has passed the first-level verification.

[0359] The second layer of validation is logical consistency validation, used to check the logical consistency between fields in the target sample data. Specific checks include: the logical matching between triggering conditions and execution actions (e.g., if the triggering condition is a time condition, the execution action should not be an operation requiring real-time user interaction); the reasonableness of the logical relationship between multiple triggering conditions (e.g., when the logical relationship is "AND," all triggering conditions should be simultaneously satisfied); the correspondence between user query statements and tool call examples (e.g., the song name mentioned in the user query statement should match the song name in the tool call parameters); and the consistency between inference content fields and task configuration (e.g., the task title should be semantically consistent with the triggering conditions and execution actions). Logical consistency validation is also automated and performs millisecond-level checks, enabling rapid detection of logical inconsistencies in the data.

[0360] Furthermore, the second layer of logical consistency verification is a scenario-level verification. It performs verification by matching business rules with scenario tag template files, covering basic process logic, scenario tag-specific logic, and scenario template rules. It is suitable for verifying data generated in batches during the data generation phase, badcase datasets, and test cases, and can include different configuration rule documents. This verification introduces a session state machine mechanism, performing verification based on finite states, tool call identifier (id) matching, and sequential structure. It uses regular expression tag configuration, with different scenario templates corresponding to different verification rules, enabling precise logical verification of data across various scenarios in YOYO tasks.

[0361] S1203: Perform a third-level verification on the target sample data that has passed the second-level verification.

[0362] The third layer of validation is semantic content validation, used to check the semantic content quality of the target sample data, including the naturalness of user queries, the reasonableness of model responses, and the correctness of tool calls. Semantic content validation can employ a large language model-assisted validation approach, where the target sample data is input into the validation model, which then judges the semantic quality of the data. Compared to relying entirely on manual review of each item, the third layer of semantic content validation, assisted by a large language model, can significantly reduce manual validation costs. Data judged as low-quality or questionable by the validation model can be marked and transferred to manual review. The third layer of semantic content validation is a large language model (LLM) level validation, making a comprehensive judgment through semantic understanding. Its scope includes the reasoning process (i.e., thought process), the open-domain standard answer (i.e., open-domain ground truth), the model response, and the reasonableness of user queries. It is suitable for problems that are difficult to validate through rule codes or configuration files. This validation introduces a large language model scoring mechanism, independently scoring the data based on four indicators: accuracy, relevance, conciseness, and structure, according to the product scoring standards, to perform semantic understanding and quality assessment. The third layer of semantic content validation module can run independently for in-depth data optimization.

[0363] The three-layer verification mechanism described above employs automated millisecond-level verification in the first and second layers, which can quickly filter out data with formatting errors and logical contradictions. The third layer performs semantic content verification, using a large language model to reduce the cost of manual verification. This progressive three-layer verification ensures both verification efficiency and high-quality training data.

[0364] S1204: Store the target sample data that passes the verification into the training dataset, or mark the target sample data that fails the verification and output an anomaly report.

[0365] The anomaly report includes information such as the identifier of the failed data, the level of validation that failed, and the specific reason for the error, which helps developers locate problems and optimize the data generation process.

[0366] As an example, the hierarchical verification method can be encapsulated into an internal platform to support automated verification of batch data and statistical analysis of verification results, making it easy to use.

[0367] It should be noted that the above three-layer verification mechanism has the following characteristics: the first and second layers of verification can quickly identify common problems and YOYO task data problems, and have strong scalability and versatility; although the third layer of verification takes longer, it can perform semantic understanding, reducing the time for manual verification and annotation; in addition, the layered verification is used in conjunction with the data production module to optimize each other's logic, which can significantly improve the efficiency and quality of data production, forming a closed-loop optimization mechanism for data production and quality verification.

[0368] Thus, the layered verification in this application embodiment filters data layer by layer from format to logic to semantics, ensuring high quality of training data.

[0369] Please see Figure 13 , Figure 13 This is a flowchart illustrating a model training method based on target training data, provided in an embodiment of this application. After generating and verifying high-quality target sample data as described above, this embodiment of the application can use the target sample data for training a task model. Specifically, the process includes the following steps:

[0370] S1301: Input the target sample data into the task model to be trained.

[0371] S1302: Perform SFT training on the task model to obtain the trained task model.

[0372] The task model refers to an intelligent assistant model used for understanding and executing conditionally triggered tasks. It can respond to user input that meets the triggering conditions and execute the corresponding conditionally triggered task. The training objective of the task model is to learn the mapping relationship from user natural language queries to task configuration (triggering conditions + execution actions + logical relationships + execution frequency), as well as complex interaction capabilities such as multi-turn interactions, follow-up questions, rejection, and tool invocation.

[0373] During supervised fine-tuning training, user queries from the target sample data serve as model input, while corresponding tool call examples, model responses, and inference process information act as supervisory signals, guiding the model to learn its ability to understand and generate conditionally triggered tasks. Through training data containing rich content such as eight scene types, complex multi-turn interactions, tool calls, and inference processes, the task model can acquire powerful understanding and execution capabilities in multi-task, multi-conditionally triggered scenarios.

[0374] Understandably, the trained task model can be deployed to electronic devices (such as smartphones, smart speakers, etc.) or cloud services to provide users with intelligent assistant services that trigger tasks based on conditions. When a user inputs a natural language description of their needs, the task model can accurately understand the user's intent, generate the corresponding task configuration, and execute the corresponding action when the triggering conditions are met, thus realizing the intelligent generation and execution of automated workflows.

[0375] Thus, the model training method provided in this application ensures that the trained model has strong generalization ability and robustness because the target sample data contains rich content such as multiple scene types, complex multi-turn interactions, tool calls, and inference processes.

[0376] like Figure 14A As shown in the figure, this application provides a YOYO intelligent agent task creation interface, deployed on terminal devices such as mobile phones 20, demonstrating the creation process of a single trigger condition + single action (single trigger + single action) type task. The application title bar of the task creation interface 41 has a back button, the application name "YOYO Task", and more operation entry points. The dialogue interaction area displays multi-round interactions between the user and the intelligent agent: the user inputs the task command "Turn on Bluetooth when opening WeChat" through natural language. This command includes a single trigger condition (opening WeChat) and a single action (turning on Bluetooth), belonging to a single trigger + single action task; after receiving the command, the intelligent agent replies "Okay, planning a task for you", confirming and starting the task parsing process. After the task parsing is completed, the interface displays the structured task results in the form of a task card. The card title is "SMS Monitoring Assistant", and the content is "Automatically turn on Bluetooth when opening WeChat", that is, the trigger condition is opening WeChat and the action is turning on Bluetooth; the upper right corner of the card has an "Execute Now" button, and the bottom has "Edit" and "Try" buttons, which respectively support the user to directly execute the task, modify the task parameters, and preview the task execution effect. The bottom input bar features a function expansion button and a voice input button, "Press and hold to speak the task," allowing users to continuously input new task commands via text or voice. Through this interface, users can easily create conditional trigger tasks of type single trigger + single action using natural language or voice. The intelligent agent automatically parses and structures the task, and provides interactive operations such as execution, editing, and trial, enabling the visual creation and management of conditional trigger tasks.

[0377] like Figure 14B As shown in the figure, this application provides a YOYO intelligent agent task creation interface, deployed on terminal devices such as mobile phones 20, demonstrating the task creation process of adding multiple actions in a multi-round interactive scenario. The dialogue interaction area in the interface 42 shows two rounds of task creation interaction between the user and the intelligent agent: In the first round, the user inputs the task instruction "Turn on Bluetooth at 8 o'clock every day" in natural language. After receiving it, the intelligent agent replies "Okay, planning the task for you" and generates a task card "Turn on Bluetooth at 8 o'clock every day", showing that the trigger condition is 8 o'clock every day and the execution action is turning on Bluetooth; In the second round, the user adds the instruction "Add a task to turn on location when executing", adding an execution action on the basis of the original task. The intelligent agent replies "Received, planning the task according to the new information" and updates the task card to "Turn on Bluetooth and location at 8 o'clock every day", showing that the trigger condition is still 8 o'clock every day and the execution actions are updated to two actions: turning on Bluetooth and turning on location, that is, expanding from a single-action task to a multi-action task; Each task card has an "Execute Now" button in the upper right corner and "Edit" and "Try" buttons at the bottom, supporting users to execute, modify and preview the task. The bottom input bar features a function expansion button and a voice input button ("Press and hold to speak the task"), allowing users to continuously add or modify tasks through multiple rounds of interaction. Through this multi-round interactive interface, users can gradually add actions to existing tasks, enabling the visual creation and dynamic expansion of tasks triggered by a single trigger and multiple action types.

[0378] like Figure 14C As shown in the figure, this application provides a YOYO intelligent agent task creation interface, deployed on terminal devices such as mobile phones 20, demonstrating the task modification process of deleting execution actions in a multi-round interactive scenario. The dialogue interaction area in the interface 43 shows the multi-round task modification interaction between the user and the intelligent agent: In the initial state, the task card displays the task "Turn on Bluetooth and location at 8 o'clock every day", the trigger condition is 8 o'clock every day, and the execution actions include turning on Bluetooth and turning on location; the user inputs "The function cannot be executed on the lock screen" in natural language, indicating that one of the execution actions cannot meet the usage needs. After receiving the input, the intelligent agent replies "Received, planning the task according to the new information", understands the user's intention, deletes the execution action that cannot be executed (turning on mobile phone location), and updates the task card to "Turn on Bluetooth at 8 o'clock every day". The execution action only retains turning on Bluetooth, that is, the multi-action task is reduced to a single-action task; each task card has an "Execute Now" button in the upper right corner and "Edit" and "Try" buttons at the bottom, supporting the user to execute, modify again and preview the modified task. After modifying the task, the agent proactively asks, "What do you want to modify? You can tell YOYO about the running conditions and specific operations through dialogue," guiding the user to continue with multiple rounds of modification or deletion. Through the above multi-round interactive interface, users can describe functional problems or deletion requests in natural language, and the agent automatically understands and deletes the corresponding execution actions, realizing multi-round dynamic reduction and fine-grained management of condition-triggered tasks.

[0379] like Figure 14D As shown in the figure, this application provides a YOYO intelligent agent task creation interface, deployed on terminal devices such as mobile phones 20, demonstrating the creation process of tasks with multiple trigger conditions and multiple actions (multiple triggers + multiple actions). In the dialogue interaction area of ​​the interface 44, the user inputs the task command "When the phone battery is above 60% and the phone's Bluetooth is on, help me turn on WiFi and remind me to eat" in natural language. This command includes two trigger conditions (phone battery above 60% and Bluetooth on), which are combined through an "AND" logical relationship, meaning that both conditions must be met simultaneously to trigger the task; it also includes two actions (turn on WiFi and remind me to eat), which are executed in parallel after the task is triggered. After receiving the command, the intelligent agent replies "Okay, planning a task for you," and after completing the task parsing, displays the structured task result in the form of a task card. The card content clearly indicates that the task trigger condition is "phone battery above 60% and Bluetooth on," and the task action is "turn on WiFi and remind me to eat." There is an "Execute Now" button in the upper right corner of the card, and "Edit" and "Try" buttons at the bottom, allowing users to directly execute tasks, modify trigger conditions or actions, and preview the task execution effect. The updated task cards display a concise summary titled "Turn on WiFi and remind me to eat when battery is above 60% and Bluetooth is on," making it easy for users to quickly identify the task. The bottom input bar features function expansion buttons and a voice input button, "Press and hold to speak the task," allowing users to continuously create or modify complex tasks with multiple triggers and actions using natural language or voice commands. Through this interface, users can easily create complex condition-triggered tasks containing multiple logical combinations of trigger conditions and multiple parallel execution actions. The intelligent agent automatically performs multi-condition logic parsing and multi-action orchestration, enabling the visual creation and management of complex tasks.

[0380] like Figure 14E As shown in the figure, this application provides a YOYO agent task creation interface, deployed on terminal devices such as mobile phones 20, demonstrating the task creation interaction process in a follow-up question scenario. In the dialogue interaction area of ​​the interface 45, the user first inputs the task instruction "Remind me when the phone battery is below 20%" in natural language. This instruction only includes the trigger condition (phone battery below 20%), but does not specify the specific execution action (i.e., the specific content and method of the reminder), which is an incomplete task instruction with missing execution action parameters. After receiving the instruction, the agent replies "Okay, planning a task for you." During the task parsing process, it recognizes the missing execution action parameters and automatically triggers the follow-up question mechanism, asking the user in the form of a follow-up question pop-up, "Paused, please provide supplementary information; when the battery is below 20%, what subsequent operation do you want me to trigger?", guiding the user to supplement the specific execution action information; a "Stop" button is provided at the bottom of the follow-up question pop-up, allowing the user to terminate the follow-up question process when no further supplementation is needed. Only after the user answers the follow-up question and supplements the complete execution action can the agent complete the structured parsing and creation of the task. The bottom input bar features a voice input button, "Press and hold to speak the task," allowing users to answer follow-up questions or input new task instructions via voice. Through this follow-up questioning mechanism, when necessary parameters are missing from the user's input task instructions, the agent can automatically identify and proactively initiate follow-up questions, guiding the user to gradually fill in the complete information. This ensures that the final condition-triggered task contains clear triggering conditions and execution actions, improving the accuracy and completeness of task creation.

[0381] like Figure 14F As shown in the figure, this application provides a YOYO intelligent agent task management interface, which is deployed on terminal devices such as mobile phones 20. Interfaces 46 and 47 respectively display two function pages: editing tasks and multi-functional editing. The task editing page in interface 46 has a title bar at the top, and displays the condition-triggered tasks created by the user in a list below, including tasks such as "read me the weather forecast and schedule every morning", "turn on music and navigation for me on my way to work every day", and "remind me to write the weekly report every Friday at 5 pm". Each task has a switch button on the right, which allows users to independently enable or disable the corresponding task. The bottom of the page has a "save" button and an "edit for intelligent agent" entry, which allows users to save changes or edit tasks through intelligent agents. Interface 47, the multi-functional editing page, displays the batch management entry point for tasks in a functional category format, including functions such as "Weather and Schedule Broadcast," "Commuting to Work," "Turn on WiFi," and "Turn on Bluetooth Alerts." Each function has a toggle button on the right, with "Weather and Schedule Broadcast" and "Commuting to Work" in the "on" state, and "Turn on WiFi" and "Turn on Bluetooth Alerts" in the "off" state. This allows users to manage the activation status of tasks in batches by function category. A "Done" button is located at the bottom of the page to confirm and exit the multi-functional editing. Through the above dual-screen editing interface, users can view and manage specific tasks one by one on the task editing page, or switch task on / off in batches by function category on the multi-functional editing page. This enables refined management of condition-triggered tasks and convenient batch operations, improving the efficiency and flexibility of task management.

[0382] like Figure 14G As shown in the comparison diagram of the YOYO agent task creation interface provided in this application embodiment, it is deployed on terminal devices such as mobile phone 20. Interface 48 is the task creation interface, and interface 49 is the slot completion query interface, demonstrating two interaction modes of automatic planning and parameter completion by the agent during the task creation process. First, interface 48 displays a task card "Weather and Schedule Broadcast". After the user clicks on the task card, interface 49, which is used for the user to manually edit the task details, can be displayed. For example, interface 49 shows the task details of the "Weather and Schedule Broadcast" task, including "8:00 AM", "Leave home", "Turn off Do Not Disturb mode", etc. Each task detail has a "Stop" button, which allows the user to terminate at any time during the planning process, reflecting the agent's ability to automatically break down tasks and execute them step by step based on a single command; the task details of the "Weather and Schedule Broadcast" task also include a "Condition Addition" control to support the user to manually add trigger conditions during the planning process. Furthermore, interface 49 displays the execution actions for the "Weather and Schedule Broadcast" task, including "Turn on WiFi" and "Turn on Mobile Data," with each action having a "Stop" button to allow users to terminate the task at any time during planning. The "Weather and Schedule Broadcast" task also includes an "Add Action" control to allow users to manually add actions during planning. Interface 49 also displays execution method options to allow users to select "Ask to Execute." Additionally, in the task creation interface 48, after the "Weather and Schedule Broadcast" task card is created, if the user enters "Read me the day's weather forecast and schedule every morning," the agent replies "Okay, creating the task for you." Further, if the user enters "Play it every morning when the alarm is off," the agent replies "Received your reply, continuing to plan the task. If you have any questions, you can tell me via voice or click the card to manually modify it." After understanding the user's intent, the agent recreates the task and replies, "Do you have any modifications you'd like? Adjusting the time, adding or deleting tasks, or changing the execution method?" Subsequently, when the user inputs the command "Change to immediate execution, and simultaneously broadcast unread text messages," the agent modifies the task and replies "Okay, modified," immediately executing the tasks of broadcasting the weather and unread text messages. A voice input button is located at the bottom: "Press and hold to speak the task." Comparing the two interfaces, it's clear that when the user's task command is complete, the agent can automatically perform multi-step task planning and directly create the task; when necessary parameters are missing, the agent proactively initiates a gap-filling query, guiding the user to gradually fill in the missing information, ensuring that the final created condition-triggered task parameters are complete and the execution is clear, achieving intelligent task creation and interactive flexibility.

[0383] Referring to Tables 1 to 3, a statistical table of evaluation indicators for a condition-triggered task model provided in the embodiments of this application is shown, which is used to quantitatively evaluate the execution effect of the task model trained by the model training method of this application in various scenarios.

[0384] Table 1:

[0385] Table 2:

[0386] Table 3:

[0387] Table 1 shows the distribution of test data volume for each scenario, covering single-round scenarios (200 entries), multi-round scenarios (129 entries), edge scenarios (261 entries), popular app list scenarios (25 entries), personal knowledge base scenarios (68 entries), replan scenarios (50 entries), alarm clock scenarios (29 entries), notification reminder scenarios (30 entries), AI button (AI reminder) scenarios (122 entries), main agent integration scenarios (90 entries), and navigation skill scenarios (146 entries), covering a comprehensive distribution of test data for single-round and multi-round, general and specific scenarios.

[0388] Table 2 shows the overall pass rate indicators. The pass rate for single-round scenarios is 100.00%, the pass rate for multi-round scenarios is 78.08%, the pass rate for edge scenarios is 79.84%, and the overall pass rate is 91.41%. This indicates that the trained task model performs well on simple single-round tasks and still has a high execution accuracy on complex multi-round and overmultiplication tasks.

[0389] Table 3 shows the pass rate indicators for each sub-scenario. The notification reminder scenario has the highest pass rate (96.67%), followed by the main agent integration scenario (87.80%), the replan scenario (88.00%), the navigation skill scenario (74.17%), the popular app list scenario (73.91%), and the personal knowledge base scenario (72.73%). This reflects the differences in model execution capabilities under different scenario types, providing a quantitative basis for subsequent data allocation optimization and model capability improvement.

[0390] Please see Figure 15 , Figure 15 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. This application also provides an electronic device 100, which can be a terminal device with data processing capabilities such as a smartphone, tablet computer, personal digital assistant, or wearable device, or it can be a server or cloud computing platform. The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a user identification module interface 195, etc.

[0391] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. Figure 15 The components shown can be implemented in hardware, software, or a combination of both.

[0392] The processor 110 may include one or more processing units, such as an application processor, a modem processor, a graphics processor, an image signal processor, a controller, a video codec, a digital signal processor, a baseband processor, and / or a neural network processor. Different processing units may be independent devices or integrated into one or more processors. In this embodiment, the processor 110 can execute various steps in the above-described model training method, including acquiring trigger-action metadata and scene configuration conditions, determining scene prompt templates and generating model input prompts, calling a large language model to generate initial sample data, and post-processing the initial sample data to obtain target sample data.

[0393] The internal memory 121 can be used to store computer executable program code, which includes instructions. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, phonebook, etc.). In this embodiment, the internal memory 121 can be used to store trigger-action metadata, scene configuration conditions, scene prompt templates, initial sample data, target sample data, training datasets, and task models, etc.

[0394] The wireless communication function of electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. In this embodiment, electronic device 100 can communicate with the server where the large language model is located through wireless communication module 160, send model input prompts to the server and receive initial sample data generated by the large language model; it can also access an external knowledge base through wireless communication module 160 to obtain tool description information and query results corresponding to auxiliary tools.

[0395] Please see Figure 16 , Figure 16 This is a schematic diagram of the operating system software structure of an electronic device provided in an embodiment of this application. The operating system of the electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the application takes the layered architecture Android system as an example to illustrate the system software structure of the electronic device 100. The layered architecture divides the software into several layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0396] The application layer may include a series of application packages, such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, SMS, and browser and instant messaging applications. In this embodiment, the application layer may also include a smart assistant application (such as YOYO Assistant, i.e., YOYO agent), which can invoke task models to provide users with intelligent generation and execution services for conditionally triggered tasks.

[0397] The application framework layer provides application programming interfaces and programming frameworks for applications in the application layer, including a window manager, content provider, view system, phone manager, resource manager, notification manager, etc. In this embodiment, the application framework layer may also include a data generation service framework, providing service interfaces such as trigger-action metadata construction, scene prompt template management, large language model invocation, post-processing, and layered validation for upper-layer applications to call.

[0398] The Android runtime consists of core libraries and a virtual machine, responsible for scheduling and managing the Android system. System libraries can include multiple functional modules, such as the surface manager, media libraries, 3D graphics processing libraries, and a 2D graphics engine. The kernel layer is the layer between hardware and software, and at least includes display drivers, camera drivers, audio drivers, and sensor drivers.

[0399] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in the above-described method embodiments. The computer-readable storage medium can be a storage unit inside an electronic device or an external storage device accessible by the electronic device, such as a plug-in hard drive, smart memory card, secure digital card, flash memory card, etc.

[0400] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps in the above-described method embodiments.

[0401] Various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or combinations of these implementation methods. Embodiments of this application can be implemented as computer program modules or module code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0402] In this specification, the reference to "an embodiment" or "an embodiment" means that a specific feature, structure, or characteristic described in connection with the embodiment is included in at least one exemplary implementation or technology disclosed according to an embodiment of this application. The appearance of the phrase "in an embodiment" in various places in the specification does not necessarily refer to the same embodiment.

[0403] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the various embodiments described above.< / summary> < / refuse> < / ask>

Claims

1. A model training method, characterized in that, include: Retrieve trigger-action metadata and scene configuration conditions; Multiple scene prompt templates that correspond to the trigger-action metadata and meet the scene configuration conditions are identified, and the trigger-action metadata is filled into the multiple scene prompt templates to generate multiple model input prompts; Call the large language model and obtain multiple initial sample data generated by the large language model based on the input prompts of the multiple models; The initial sample data is post-processed to obtain multiple target sample data, which are used for model training.

2. The method according to claim 1, characterized in that, The acquisition of trigger-action metadata includes: Obtain tool definitions and tool common scenario slot mapping tables. The tool definitions include at least one of the following: tool identifier, tool description, and parameter list. The tool common scenario slot mapping tables include at least one common scenario corresponding to each tool and its slot value template. Iterate through each tool in the tool definition and match the common scenarios corresponding to each tool according to the common scenario slot mapping table of the tools; For each common scenario matched, the slot is instantiated according to the slot value template to obtain the corresponding parameter value; Triggering conditions are generated based on the scene description and instantiated parameter values, and execution actions are generated based on the tool identifier and instantiated parameter values. The triggering conditions and execution actions are paired and combined to obtain the trigger-action metadata.

3. The method according to claim 1, characterized in that, The scenario configuration conditions include a scenario description, a list of available tools, and interaction constraints. The determination of multiple scene prompt templates that correspond to the trigger-action metadata and meet the scene configuration conditions includes: The target scenario category is determined based on the triggering conditions and execution actions in the trigger-action metadata. Retrieve the scene configuration conditions corresponding to the target scene category from the preset scene configuration library; Based on the preset scene generation ratio, multiple scene prompt templates that meet the scene configuration conditions are dynamically selected from the scene configuration library.

4. The method according to claim 3, characterized in that, The scene prompt templates are stored in the form of prompt words and skills, and can be added or deleted.

5. The method according to claim 1, characterized in that, The scene prompt template includes modal word configuration, sentence template and character description, which are used to guide the large language model to generate dialogue data that conforms to the target scene category; The step of filling the trigger-action metadata into the multiple scene prompt templates to generate multiple model input prompts includes: The triggering conditions and execution actions in the trigger-action metadata are used as slot values ​​and filled into the corresponding slots of each scene prompt template to generate multiple model input prompts.

6. The method according to claim 1, characterized in that, The process of calling the large language model and obtaining multiple initial sample data generated by the large language model based on the input prompts of the multiple models includes: For different scenario prompt templates, different large language model interfaces are called in parallel to generate data, and multiple initial sample data generated by each language model based on the corresponding model input prompts are obtained.

7. The method according to claim 1, characterized in that, The large language model generates multiple initial sample data based on the input prompts from the multiple models, including: The method of generating user query statements by reverse engineering from the standard answer corresponding to the trigger-action metadata is adopted. Based on the triggering conditions and execution actions in the trigger-action metadata, the large language model generates user query statements corresponding to the standard answer, which are used as user query statements in the initial sample data.

8. The method according to claim 1, characterized in that, The initial sample data includes user query statements, model responses, and tool call examples; The scenario types corresponding to the initial sample data include at least one of the following: simple scenario, logical AND / OR scenario, multi-action scenario, follow-up questioning scenario, rejection scenario, independent multi-task scenario, multi-round modification scenario, and multi-round addition scenario.

9. The method according to claim 1, characterized in that, The post-processing of the multiple initial sample data to obtain multiple target sample data includes: The initial sample data is parsed to extract tool call information and scene feature information; The tool call information is matched with a preset tool set, and the scene feature information is matched with a preset scene category; The initial sample data that is successfully matched is identified as the data to be enhanced. The data to be enhanced is then subjected to multiple rounds of interactive expansion to generate multi-round interactive logic that includes at least one of the following: confirmation round, parameter inquiry round, modification round, and result feedback round, thereby obtaining the enhanced data.

10. The method according to claim 9, characterized in that, The multi-round interactive expansion of the data to be enhanced includes: Based on the triggering conditions and execution actions in the data to be enhanced, determine the types of interaction rounds that need to be supplemented; Based on the interaction round type, a corresponding scene template is selected from the preset scene template library. The scene templates are stored in the form of prompt words and skills, and can be added or deleted. Based on the scene template and the context information in the data to be enhanced, supplementary interaction round data is generated; The supplementary interaction round data is concatenated with the data to be enhanced to obtain enhanced data containing multi-round interaction logic.

11. The method according to claim 9, characterized in that, After obtaining the enhanced data by performing multiple rounds of interactive expansion on the data to be enhanced, the method further includes: For augmented data that requires the assistance of auxiliary tools, post-processing of the tools is performed. The post-processing of the tools includes: calling an external knowledge base to obtain the tool description information corresponding to the auxiliary tool; performing reasoning based on the tool description information to generate query information; executing a query based on the query information to obtain query results; and updating the augmented data based on the query information and the query results to make the updated data conform to the format requirements of the auxiliary tool.

12. The method according to claim 9, characterized in that, After obtaining the enhanced data by performing multiple rounds of interactive expansion on the data to be enhanced, the method further includes: For augmented data that hits a set scenario, post-processing of the set scenario is performed. The post-processing of the set scenario includes: identifying the set scenario type corresponding to the augmented data. The set scenario type includes at least one of personal knowledge base scenario, address list selection scenario, and workflow modification scenario. Call the scene post-processing template corresponding to the set scene type; The augmented data is updated according to the preset scene branch ratio to generate training data containing complex rounds of interaction and multiple branches of sub-scenes. The scenario branches include at least one of the following: empty address query, multiple address queries, query error, and unique query result. Different scenario branches correspond to different orchestration and interaction logic.

13. The method according to claim 1, characterized in that, The post-processing of the multiple initial sample data to obtain multiple target sample data includes: The initial sample data and / or the enhanced data after multiple rounds of interaction expansion are further processed to obtain the corresponding target sample data. The further processing includes at least one of the following: scene label generation, reasoning process generation, tool execution result generation, and interaction script polishing. The scene tag generation includes: judging user query statements in at least one of the initial sample data and the enhanced data in descending order of priority; if a set scene is matched, the subsequent judgment stops and the corresponding scene tag is generated.

14. The method according to claim 13, characterized in that, The reasoning process is generated including: Determine whether the scene tag is a set scene tag, wherein the set scene tag includes at least one of the following: follow-up question scene tag, rejection scene tag, and personal knowledge base scene tag; If the scene label is the set scene label, call the set scene thinking process generation file to generate special reasoning process information containing at least one of the following: follow-up questioning thinking content, rejection thinking content, or thinking content called by auxiliary tools; If the scene label is not the set scene label, call the general thinking process generation file to generate reasoning process information containing at least one of the following: task title, task description, trigger description, execution action description, and chain-like reasoning process.

15. The method according to claim 13, characterized in that, The tool's execution results include: Update the tool registration results and the model response information according to the random probability of the triggering conditions and the actions performed.

16. The method according to claim 13, characterized in that, The polishing of the interactive dialogue includes: When the scenario tag is a follow-up scenario tag or a rejection scenario tag, the polishing model is invoked to polish the model's response and generate standardized interactive dialogue.

17. The method according to claim 1, characterized in that, The trigger-action metadata, the initial sample data, and the target sample data are all carried using a unified task data structure, which includes: Basic message fields are used to store user query statements and model responses; The embedded task tool field adopts an embedded decoupled structure, including mutually independent trigger condition subfields, execution action subfields, logical relationship subfields, and execution frequency subfields, which are used to carry the corresponding task configuration information. The extended fields include a reasoning content field, a scene tag field, a tool execution result subfield, and an interaction script subfield, wherein the reasoning content field is used to store reasoning process information, the scene tag field is used to store scene tags, the tool execution result subfield is used to store tool execution results, and the interaction script subfield is used to store interaction scripts.

18. The method according to claim 17, characterized in that, The inference content fields include: The task title subfield is used to store the identifier name of the condition-triggered task; The task description subfield is used to store a natural language description of the condition-triggered task; The trigger descriptor subfield is used to store natural language description information of the triggering conditions; The execution action description subfield is used to store natural language description information of the execution action; The "Follow-up Questions" subfield is used to store interactive scenario information that needs to be asked of the user when parameters are incomplete. The Rejection Scenario subfield is used to store rejection response information when the triggering condition is not met or the intent cannot be recognized; The model response subfield is used to store standardized response information after task execution.

19. The method according to claim 18, characterized in that, The reasoning content field is organized using a chain-like thinking structure, which includes at least one of the following: chain-like thinking reasoning process, task title, task description, trigger description, execution action description, follow-up questioning scenario, rejection scenario, and model response; each subfield of the reasoning content field is decomposed and applied to the task creation, task execution, and user interaction stages respectively.

20. The method according to any one of claims 17 to 19, characterized in that, In the embedded decoupling structure, the triggering conditions, execution actions, logical relationships, and execution frequencies are configured independently of each other.

21. The method according to any one of claims 17 to 19, characterized in that, The basic message field of the task data structure adopts a message sequence structure consistent with the standard supervised fine-tuning format, and each message contains a role identifier and message content; the embedded decoupling structure is embedded in the basic message field in the form of extended fields.

22. The method according to claim 17, characterized in that, The method further includes: During the trigger-action metadata acquisition phase, the trigger condition and the execution action are respectively filled into the trigger condition subfield and the execution action subfield; During the initial sample data generation phase, user query statements and model responses are backfilled into the basic message field, and tool call examples are backfilled into the embedded task tool field. In the post-processing stage, the multi-round interaction logic is backfilled into the message sequence of the basic message field, and the scene tags, inference process information, tool execution results and interaction scripts are backfilled into the scene tag field, the inference content field, the tool execution result subfield and the interaction script subfield, respectively.

23. The method according to claim 1, characterized in that, After post-processing the multiple initial sample data to obtain multiple target sample data, the process further includes: The target sample data is subjected to layered verification, which includes a first layer of format verification, a second layer of logical consistency verification, and a third layer of semantic content verification. The target sample data that passes the verification is stored in the training dataset, and the target sample data that fails the verification is marked and an anomaly report is output.

24. The method according to claim 1 or 23, characterized in that, The method further includes: The target sample data is input into the task model to be trained, and the task model is subjected to supervised fine-tuning training to obtain the trained task model. The task model is used to execute corresponding condition-triggered tasks in response to user input that meets the triggering conditions.

25. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the method as described in any one of claims 1 to 24.

26. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 24.

27. A computer program product, characterized in that, Includes a computer program / instruction, which, when executed by a processor, implements the method as described in any one of claims 1 to 24.

Images