Domain reasoning model training method and device, domain reasoning model using method and device, equipment and medium

Abstract

The invention provides a domain reasoning model training method and device, a domain reasoning model using method and device, equipment and a medium, and relates to the artificial intelligence technology. The domain inference model training method comprises the steps that an original domain model is finely adjusted based on a preset inference data set, and an intermediate model with the inference capability is obtained; the preset reasoning data set is generated by reasoning general open source data through a reasoning model and comprises reasoning process data and reasoning conclusion data which conform to the output form of the target domain; based on the current inference data set, performing iterative training on the basis of the original domain model to obtain a domain inference model; wherein in each iteration process, the current reasoning data set is updated based on the field problem data set and a current intermediate model obtained based on the current reasoning data set in the current iteration process; the domain problem data set comprises task feature information of the target domain. By means of the method, the domain model reasoning effect can be effectively improved.

Description

Technical Field

[0001] This application relates to artificial intelligence technology, and more particularly to a method for training, using, apparatus, device, and medium for a domain reasoning model. Background Technology

[0002] In highly specialized scenarios where domain data is largely closed, the execution of core tasks often relies on outputs that conform to domain rules (such as scripts, instruction sequences, and professional reports). These outputs must not only strictly adhere to domain-specific rules but also possess deep reasoning capabilities to handle complex scenarios. Traditional manual or template-based generation methods suffer from low efficiency and poor adaptability, thus necessitating the introduction of reasoning models to achieve automated and high-precision generation.

[0003] For domain-specific reasoning models, the training process heavily relies on a large amount of high-quality reasoning data (i.e., samples containing intermediate reasoning steps). This data is the core basis for the model to learn domain-specific reasoning logic and master rule application methods. Currently, the reasoning data relied upon by reasoning models in closed domain data scenarios is mainly obtained through two methods: one is reinforcement learning, which uses the execution results of instructions in a closed system (such as grammatical compliance and process completion) as feedback signals, and iteratively optimizes the model output through reinforcement learning algorithms to indirectly accumulate reasoning data; the other is direct distillation of general reasoning models, which utilizes the reasoning capabilities of general large models to generate reasoning data for the target domain and perform knowledge transfer.

[0004] However, obtaining inference data through any of the above methods will result in poor inference performance when the inference model is used to handle tasks in closed scenarios. Summary of the Invention

[0005] This application provides a training method, usage method, apparatus, device, and medium for a domain reasoning model, in order to improve the reasoning performance of the domain reasoning model.

[0006] Firstly, this application provides a method for training a domain reasoning model, the method comprising:

[0007] The original domain model is fine-tuned based on a pre-set inference dataset to obtain an intermediate model with inference capabilities; the pre-set inference dataset is generated by inferring general open-source data through the inference model, and includes inference process data and inference conclusion data that conform to the output form of the target domain.

[0008] Based on the current inference dataset, iterative training is performed on the original domain model until the iteration termination condition is met to obtain the domain inference model of the target domain; wherein, in each iteration, the current inference dataset is updated based on the domain problem dataset of the target domain and the current intermediate model obtained based on the current inference dataset in the current iteration; the domain problem dataset contains task feature information of the target domain.

[0009] In another possible implementation, updating the current inference dataset based on the domain problem dataset of the target domain and the current intermediate model obtained during the current iteration based on the current inference dataset includes:

[0010] Each domain problem data in the domain problem dataset is input into the current intermediate model to generate corresponding domain reasoning data; the domain reasoning data includes domain reasoning process data and domain reasoning conclusion data.

[0011] Select target data that meets the first preset condition from the reasoning data of each domain, and update the current reasoning dataset according to the target data and the corresponding domain question data; the first preset condition includes at least one of the following: correct format, correct conclusion.

[0012] In another possible implementation, the step of inputting the domain problem data from the domain problem dataset into the current intermediate model to generate corresponding domain inference data includes:

[0013] For each domain problem data in the domain problem dataset, the current intermediate model is controlled to perform a preset number of samplings at a preset output temperature to generate a corresponding preset number of domain inference data.

[0014] In another possible implementation, the step of filtering target data that meets the first preset condition from the inference data of each of the said domains includes:

[0015] For any domain of problem data, first candidate data is selected based on the first sub-preset condition; the first sub-preset condition includes: correct format;

[0016] Extract the domain reasoning conclusion data from the first candidate data, and filter the second candidate data according to the second sub-preset condition; the second sub-preset condition includes: the conclusion is correct;

[0017] The target data is determined based on the second candidate data.

[0018] In another possible implementation, determining the target data based on the second candidate data includes:

[0019] Obtain the domain characteristic requirements; the domain characteristic requirements include at least one of the following: the minimum number of reasoning steps required by the target domain, and the strictness level of the script syntax;

[0020] The target data is selected from the second candidate data based on the domain characteristics requirements.

[0021] In another possible implementation, determining the target data based on the second candidate data includes:

[0022] Obtain demand information; the demand information includes at least one of the following: user historical habits, user needs; wherein, the user historical habits are used to indicate the domain reasoning conclusion data needs corresponding to historical domain problem data;

[0023] The target data is selected from the second candidate data based on the required information.

[0024] In another possible implementation, the method further includes:

[0025] In each iteration, the current inference dataset is fine-tuned based on the original domain model to obtain the current intermediate model; wherein, in the first iteration, the current inference dataset is obtained by updating the preset inference dataset using the domain problem dataset and the intermediate model.

[0026] In another possible implementation, the method further includes:

[0027] Collect a dataset of questions that meet the second preset conditions from general open-source data;

[0028] The reasoning model is used to process the problem dataset to generate reasoning data corresponding to each problem data in the problem dataset, and the problem data and the reasoning data are used to form the preset reasoning dataset; wherein, the reasoning process data is a long thought chain containing logical steps.

[0029] In another possible implementation, the second preset condition includes at least one of the following: belonging to the mathematical or code domain and containing keywords for indicating multi-step reasoning, and having the same logical type as the target domain; wherein the logical type includes step-by-step decision-making, constraint verification, or multivariate optimization.

[0030] In another possible implementation, the fine-tuning of the original domain model based on a preset inference dataset to obtain an intermediate model with inference capabilities includes:

[0031] For each training sample in the preset inference dataset, the question data and inference data are separated; the inference data includes inference process data and inference conclusion data.

[0032] Using the problem data as input and the inference data as the target output, the original domain model is fine-tuned to obtain the intermediate model; wherein, during fine-tuning, the loss weight of the inference process data is made higher than the loss weight of the inference conclusion data.

[0033] In another possible implementation, when the target domain is Electronic Design Automation (EDA), the domain problem data input to the domain inference model is electronic design requirement data, and the output domain inference data is design inference process data and domain inference conclusion data is electronic design script data. The electronic design script data is used to obtain an electronic design scheme.

[0034] Secondly, this application provides a method for using a domain reasoning model, the method comprising:

[0035] The domain question-and-answer data of the target domain is input into the domain reasoning model trained by the method described in any of the first aspects to obtain domain reasoning data; the domain question-and-answer data is task feature information used to trigger the preset task of the target domain, and the domain reasoning data includes domain reasoning process data and domain reasoning conclusion data corresponding to the domain question-and-answer data.

[0036] The domain reasoning conclusion data is extracted from the domain reasoning data, and an executable solution for the target domain is determined based on the domain reasoning conclusion data; the executable solution conforms to the proprietary rules and technical specifications of the target domain.

[0037] Thirdly, this application provides a training apparatus for a domain reasoning model, the apparatus comprising:

[0038] The fine-tuning module is used to fine-tune the original domain model based on a preset inference dataset to obtain an intermediate model with inference capabilities. The preset inference dataset is generated by inferring general open-source data through the inference model and includes inference process data and inference conclusion data that conform to the output format of the target domain.

[0039] The training module is used to iteratively train the original domain model based on the current inference dataset until the iteration termination condition is met to obtain the domain inference model of the target domain; wherein, in each iteration, the current inference dataset is updated based on the domain problem dataset of the target domain and the current intermediate model obtained based on the current inference dataset in the current iteration; the domain problem dataset contains task feature information of the target domain.

[0040] Fourthly, this application provides an apparatus for using a domain reasoning model, the apparatus comprising:

[0041] The input module is used to input domain question-and-answer data of the target domain into the domain reasoning model trained by the method described in any one of the first aspects to obtain domain reasoning data; the domain question-and-answer data is task feature information used to trigger a preset task in the target domain, and the domain reasoning data includes domain reasoning process data and domain reasoning conclusion data corresponding to the domain question-and-answer data.

[0042] The determination module is used to extract the domain reasoning conclusion data from the domain reasoning data, and determine the executable solution for the target domain based on the domain reasoning conclusion data; the executable solution conforms to the proprietary rules and technical specifications of the target domain.

[0043] Fifthly, this application provides an electronic device, comprising: at least one processor and a memory;

[0044] The memory stores computer-executed instructions;

[0045] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method as described in either the first or second aspect above.

[0046] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a central processing unit, are used to implement the method described in any one of the first or second aspects above.

[0047] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a central processing unit, implements the method described in either the first or second aspect.

[0048] This application provides a training method, usage method, apparatus, device, and medium for a domain reasoning model. The method is executed by any electronic device. The training method proposes processing general open-source data using a reasoning model to generate a pre-defined reasoning dataset containing reasoning data. Based on this dataset, the original domain model is fine-tuned to obtain an intermediate model. Then, through iterative interaction between the intermediate model and the domain problem dataset, the current reasoning dataset is continuously updated, and the original domain model is trained, ultimately yielding the domain reasoning model. In this process, by using high-quality reasoning data generated by the reasoning model as the initial training foundation, the shortcomings of reinforcement learning methods, such as fuzzy reward signals, low sample efficiency, and susceptibility to local optima, are avoided. Simultaneously, through iterative interaction between the domain problem dataset and the intermediate model, the reasoning data continuously focuses on a specific domain, solving the problem of weak domain specificity caused by the distillation method of general reasoning models. The finally trained domain reasoning model significantly improves reasoning accuracy, logical coherence, and domain adaptability within closed domains such as electronic design automation, effectively enhancing the reasoning capability of the domain model. Attached Figure Description

[0049] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0050] Figure 1 A schematic diagram illustrating an application scenario of a training method for a domain reasoning model provided in an embodiment of this application;

[0051] Figure 2 A flowchart illustrating a method for training a domain reasoning model provided in this application embodiment. Figure 1 ;

[0052] Figure 3 A flowchart illustrating a method for training a domain reasoning model provided in this application embodiment. Figure 2 ;

[0053] Figure 4 A flowchart illustrating a method for training a domain reasoning model provided in this application embodiment. Figure 3 ;

[0054] Figure 5 A schematic diagram illustrating the process of training a domain reasoning model provided in an embodiment of this application;

[0055] Figure 6 A flowchart illustrating a method for using a domain reasoning model provided in an embodiment of this application;

[0056] Figure 7 A schematic diagram of the structure of a training device for a domain reasoning model provided in an embodiment of this application;

[0057] Figure 8 A schematic diagram of the structure of a device for using a domain reasoning model provided in an embodiment of this application;

[0058] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0059] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0061] In highly specialized scenarios where domain data is highly closed, such as specific industrial control systems, confidential industry business processing, and niche professional tool operations, the execution of core tasks often relies on the precise generation of scripts, instruction sequences, or process configuration files. Task processing in these scenarios must simultaneously meet two core requirements: first, absolute adherence to domain-specific rules, including the proprietary syntax of closed systems (such as command formats for internal tools), industry-specific parameter constraints (such as permission thresholds for confidential domains), and undisclosed process logic (such as linkage protocols for niche equipment); second, the ability to perform deep reasoning in complex scenarios, such as adjusting operation sequences based on dynamic feedback in multi-step task scheduling, and resolving rule conflicts to generate adaptive solutions in cross-module collaboration.

[0062] Faced with such highly closed and specialized scenarios, traditional task processing models are gradually revealing irreconcilable contradictions. Specifically, traditional manual coding or template-based generation methods have the following limitations: human intervention is prone to misunderstanding of rules due to the closed nature of domain knowledge; fixed templates are unable to cope with dynamic changes in scenarios and are inefficient. Therefore, it is urgent to introduce reasoning models, which can autonomously complete logical deduction and rule mapping to achieve automated and high-precision generation of task-driven instructions.

[0063] It should be understood that the performance of inference models is highly dependent on high-quality inference data. In closed domains, the acquisition of such data becomes a key bottleneck restricting model performance. Currently, in closed domain data scenarios, the inference data (i.e., samples containing intermediate inference steps) on which inference models rely are mainly acquired in two ways: First, reinforcement learning, which uses the execution results of instructions in a closed system (such as grammatical compliance and process completion) as feedback signals, and optimizes the model output through iterative optimization algorithms, indirectly accumulating inference data. However, this method requires high-frequency interaction with the closed system, and due to the closed nature of the data, the feedback cycle is long and quantification is difficult. Second, direct distillation of general inference models, which utilizes the inference capabilities of general large models to generate long thought chain data in the target domain and perform knowledge transfer. For example, "the steps to resolve permission conflicts in a closed system" can be derived through a general model and used as training data.

[0064] Specifically, the aforementioned reinforcement learning methods are not only limited by the closed nature of domain data, resulting in scarce or ambiguous feedback signals, easily broken logical chains of inference data, and difficulty for the model to learn complete inference paths; but also highly dependent on the capabilities of the basic model and a reliable and stable reward feedback system. If the capabilities of the basic model are insufficient or the reward system is biased, it is very easy to cause the model to crash or fail to converge. Moreover, its training requires a lot of resources, making it difficult to implement in resource-limited closed domain scenarios.

[0065] The aforementioned method of directly distilling a general model often results in "knowledge illusions" in the generated inference data (such as fictitious command formats and obfuscated permission levels) because the knowledge of the closed domain is not covered by the general model (e.g., private rules and internal protocols). This leads to a disconnect between the inference logic and the actual scenario.

[0066] As can be seen from the above, both of these methods will result in chaotic reasoning steps, incorrect rule application, and insufficient validity of generated instructions or scripts when the inference model is dealing with tasks in closed scenarios, thus failing to meet the stringent requirements of the domain for accuracy and reliability.

[0067] Therefore, this application provides a training method, usage method, apparatus, device, and medium for a domain inference model to solve the above-mentioned problems. Specifically, the training method for the domain inference model of this application proposes to process general open-source data through an inference model to generate inference data that conforms to the output format of the target domain to construct a preset inference dataset; based on this, the original domain model is fine-tuned to obtain an intermediate model, and then the intermediate model is interactively iterated with the domain problem dataset of the target domain. Each iteration generates and filters domain inference data to update the dataset, and the original domain model is continuously trained until the iteration terminates, finally obtaining the domain inference model.

[0068] It should be understood that the method of this application can be executed by any electronic device and applied to the training scenario of any closed domain inference model. As an example, Figure 1 This is a schematic diagram illustrating an application scenario of a training method for a domain reasoning model provided in an embodiment of this application, such as... Figure 1 As shown, the domain inference model training method of this application can be applied to the Electronic Design Automation (EDA) scenario. In this scenario, because the EDA domain involves highly specialized and closed knowledge such as chip design rules, routing constraints, and timing analysis, and contains a large number of proprietary script syntaxes and tool protocols, traditional reinforcement learning is difficult to apply due to the ambiguity of reward signals (such as the difficulty in quantifying chip performance indicators) and excessive resource consumption. Directly distilling a general model is also prone to rule confusion or syntax errors, resulting in broken inference logic and low instruction generation accuracy in the trained model.

[0069] like Figure 1 As shown, the electronic device interacts with the device that sets up the EDA tool. Based on the training method of this application, the electronic device first processes relevant questions that meet the conditions in general open-source data through an inference model to generate a preset inference dataset containing long thought chains; based on this dataset, it fine-tunes the original domain model to obtain an intermediate model with inference capabilities; then, through the interaction and iteration between the domain problem dataset and the intermediate model in the EDA domain, it continuously updates the preset inference dataset and trains the original domain model until the iteration termination condition is reached, finally obtaining a domain inference model suitable for EDA scenarios. The electronic device distributes this domain inference model to the device that sets up the EDA tool, enabling it to process the tasks of the EDA tool based on this domain inference model.

[0070] In this embodiment, the domain inference model can generate design scripts containing complete inference steps for tasks such as wiring rule verification and timing constraint checking in the EDA domain, and the inference process strictly follows the private syntax and industry standards of EDA tools.

[0071] The above settings effectively solve the model training problem caused by data closure in the EDA field, significantly improving the inference accuracy, rule compliance, and script effectiveness of the domain inference model in complex chip design tasks, and meeting the stringent requirements of the EDA field for accuracy and reliability.

[0072] It is understood that the electronic device can be any device such as a mobile phone or tablet, and this application does not limit it. In addition, besides the above-mentioned application scenarios, the method of this application can also be used in closed domain scenarios such as industrial control system script generation, business process reasoning in classified industries, and operation instruction generation for niche professional tools, and can also be applied to non-closed domain scenarios, which this application does not limit.

[0073] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Where the embodiments do not conflict, the following embodiments and features thereof can be combined with each other.

[0074] This application provides a method for training a domain reasoning model, specifically executed by any electronic device. Figure 2 A flowchart illustrating a method for training a domain reasoning model provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the method provided in this embodiment includes:

[0075] S201, fine-tunes the original domain model based on a pre-set inference dataset to obtain an intermediate model with inference capabilities.

[0076] The preset inference dataset is generated by inference modeling general open source data, and includes inference process data and inference conclusion data that conform to the output format of the target domain.

[0077] It should be understood that the target domain can be any domain, such as EDA, financial risk control, medical diagnostics, industrial control systems, etc. The original domain model is a network model pre-trained based on domain knowledge of the current target domain. The inference model is a general-purpose large model with strong logical reasoning capabilities, capable of performing multi-step inference on general open-source data and generating inference results containing complete logical chains, and adaptable to the rule mapping needs of different domains.

[0078] Based on this, in this embodiment, the electronic device fine-tunes the original domain model based on preset inference data obtained from the inference model, thereby obtaining an intermediate model with inference capabilities. Since the original domain model possesses domain knowledge, and the preset inference data contains inference logic and results that conform to the output format of the target domain, the intermediate model possesses domain knowledge of the target domain and has the ability to generate inference data.

[0079] The output format specifically refers to the specific format, structure, and data organization of the inference results in the target domain, conforming to the technical specifications or tool requirements of that domain. It is a concrete manifestation of the domain's characteristics. For example, in the EDA domain, it may be a code structure conforming to Verilog syntax and a script that can be parsed by EDA tools; in the financial risk control domain, it may be a tabular process containing risk calculation steps and a structured conclusion of "risk level + score"; in the medical diagnosis domain, it may be a text-based inference process following clinical pathways and diagnostic conclusions containing ICD codes, etc. It is determined by the domain's technical specifications, tool characteristics, or industry practices, ensuring that the inference data can be directly adapted to the subsequent processing flow of the domain. This is the core characteristic that the inference data generated by the intermediate model has domain applicability.

[0080] In this embodiment, the preset inference dataset includes problem data and inference data from general open-source data. The inference data includes inference process data and inference conclusion data generated from the problem data in the general open-source data, conforming to the output format of the target domain. It should be understood that the problem data in the general open-source data represents general scenario problems outside the target domain, rather than the professional task requirements of the target domain.

[0081] S202, based on the current inference dataset, iteratively trains the original domain model until the iteration termination condition is met to obtain the domain inference model of the target domain.

[0082] In each iteration, the current inference dataset is updated based on the domain problem dataset of the target domain and the current intermediate model obtained based on the current inference dataset in the current iteration; the domain problem dataset contains task feature information of the target domain.

[0083] In this embodiment, the electronic device further trains the original domain model based on the current inference dataset using an iterative training method to improve inference accuracy. Specifically, in each iteration, after fine-tuning the original domain model based on the current inference dataset, the electronic device updates the current inference dataset used in the current iteration based on the domain problem dataset of the target domain and the current intermediate model, obtaining a new current inference dataset for use in the next iteration. This continues until the iteration termination condition is finally met, at which point the current intermediate model obtained by fine-tuning the original domain model based on the current inference dataset used in the current iteration is used as the domain inference model.

[0084] It should be understood that in each iteration, the original domain model is fine-tuned based on the current inference dataset to obtain the current intermediate model. Specifically, in the first iteration, the current inference dataset is obtained by updating the preset inference dataset using the domain question dataset and the intermediate model in S201. In subsequent iterations, the current inference dataset is the updated inference dataset obtained in the previous iteration based on the domain question dataset and the current intermediate model. Specifically, the intermediate model generates corresponding inference data by inputting questions from the domain question dataset. It then filters valid data from the generated inference data that conforms to the target domain output format (e.g., correct format, grammatical compliance, logical completeness), integrates this valid data with the corresponding domain question data, and uses this data to expand or replace the original current inference dataset, thus achieving dynamic updates to the dataset.

[0085] In this embodiment, the iteration termination condition specifically includes at least one of the following: the preset number of iterations reaches a threshold, the inference accuracy of the current intermediate model on the validation set is stable above the preset threshold (e.g., the accuracy fluctuation is less than 1% for 3 consecutive iterations), or the proportion of valid data that conforms to the domain rules in the generated inference data reaches a preset proportion (e.g., more than 90%).

[0086] In practical applications, the iteration termination condition can also be flexibly set according to the accuracy requirements of the target domain. For example, in scenarios with extremely high reliability requirements (such as medical diagnosis), the termination condition can be set to the accuracy of the inference data output by the model reaching 100% after verification by domain experts. In scenarios where efficiency is the priority, it can be simplified to a fixed number of iterations or a training time threshold. This embodiment does not limit this.

[0087] It should be understood that the domain reasoning model obtained through the above process takes the input domain problem data and the output domain reasoning data corresponding to the domain problem data as the training objective in each training process. The domain reasoning data includes domain reasoning process data and domain reasoning conclusion data. Based on this setting, when the above domain reasoning model is applied and receives domain problem data, it can output the corresponding domain reasoning process data and domain reasoning conclusion data.

[0088] Furthermore, it should be understood that in different target domains, problem data refers to the task requirements or professional problems to be solved that are specific to that domain; reasoning process data refers to the logical steps and analysis processes derived based on domain-specific rules; and reasoning conclusion data refers to the result information that conforms to domain specifications and can be directly used for execution or decision-making. For example, when the target domain is EDA, the domain problem data is electronic design requirement data, the domain reasoning data is design reasoning process data, and the domain reasoning conclusion data is electronic design script data, which is used to obtain electronic design solutions.

[0089] In the method provided in this embodiment, inference models are used to perform inference on general open-source data to generate a preset inference dataset containing inference data. Based on this, the original domain model is fine-tuned to obtain an intermediate model that can generate inference data. Subsequently, by using the interaction and iteration between the intermediate model and the domain problem dataset, the preset inference dataset is continuously updated and the original domain model is trained to finally obtain the domain inference model.

[0090] The method provided in this embodiment can use high-quality inference data generated by the inference model as the initial training basis, thereby avoiding the shortcomings of reinforcement learning in terms of fuzzy reward signals, low sample efficiency, and susceptibility to local optima. Simultaneously, through iterative interaction between the domain problem dataset and the intermediate model, the inference data continuously concentrates on a specific domain, solving the problem of insufficient domain specificity in general inference model distillation. The domain inference model trained in this way exhibits significantly improved inference accuracy, logical coherence, and domain adaptability in closed domains such as electronic design automation, effectively enhancing the inference capability of the domain model.

[0091] As further explanation, Figure 3 A flowchart illustrating a method for training a domain reasoning model provided in this application embodiment. Figure 2 This embodiment, based on the foregoing embodiments, provides a detailed explanation of the process of updating the current inference dataset during each iteration. It should be understood that the updated inference dataset during each iteration is used in the next iteration. For example... Figure 3 As shown, the method in this embodiment includes:

[0092] S301: Input the domain problem data from the domain problem dataset into the current intermediate model to generate the corresponding domain inference data.

[0093] Domain reasoning data includes domain reasoning process data and domain reasoning conclusion data.

[0094] As discussed above, while the current intermediate model possesses the ability to output inference data, its accuracy is relatively low due to the lack of fine-tuning training on domain data within the target domain. Therefore, it is necessary to supplement the domain data to further improve the inference capability of the final domain inference model. In this embodiment, the electronic device employs a method of multiple sampling and verification filtering of problem data from various domains to continuously expand the domain data in the current inference dataset.

[0095] In this embodiment, the electronic device implements a multiple sampling and verification filtering process using the current intermediate model. Specifically, for each domain question data point in the domain question dataset, the electronic device controls the current intermediate model to perform a preset number of samplings at a preset output temperature, generating a corresponding preset number of domain inference data points.

[0096] More specifically, in this embodiment, the preset output temperature is 0.8, the preset number of times is 8, and correspondingly, the preset number of records is 8. The output temperature is used to adjust the randomness of the model's output. A higher temperature value results in greater diversity of output results but may reduce stability; a lower temperature value results in output concentrated on high-probability results but limited diversity. The preset number of times determines the sampling coverage; more times make it easier to generate candidate data covering different inference paths, increasing the probability of selecting high-quality data. In practical applications, the preset output temperature and preset number of times can also be configured to other values, such as setting the output temperature to 0.5 to enhance result stability, or setting the preset number of times to 10 to expand the sampling range. This embodiment does not limit this.

[0097] In the above process, the electronic device controls the randomness of sampling for each domain problem data by using a fixed temperature parameter, and generates multiple inference data by repeatedly sampling multiple times. This ensures that the data covers different logical paths while avoiding the random deviation of a single output.

[0098] The above settings can expand the coverage of inference data through multiple rounds of sampling, capture inference logic from different perspectives to improve data diversity, and balance randomness and stability by fixing the output temperature, reducing the generation of invalid or deviating data from the domain rules, laying the foundation for subsequent screening of high-quality domain data, thereby efficiently expanding the current inference dataset.

[0099] As another possible approach, electronic devices can constrain the sampling process by introducing domain-specific rule templates: first, a framework for the inference steps of the target domain is pre-defined (such as the fixed process of "requirements analysis → rule matching → script generation" in EDA). The current intermediate model must strictly adhere to this framework structure when generating inference data. Simultaneously, diverse content is generated through single high-temperature sampling, and then data with structural violations is eliminated through template validation. This method reduces invalid sampling through structured constraints, improving expansion efficiency while ensuring data standardization.

[0100] S302, select target data that meets the first preset condition from the reasoning data of each domain, and update the current reasoning dataset according to the target data and the corresponding domain question data.

[0101] The first precondition includes at least one of the following: correct format, correct conclusion.

[0102] In this embodiment, the electronic device filters data with correct format and correct conclusions from the domain inference data as target data. It should be understood that the target data includes data consistent with the domain inference data, including both domain inference process data and domain inference conclusion data. The electronic device supplements the target data with the corresponding domain question data into a preset inference dataset, thereby updating the current inference dataset.

[0103] As one possible implementation, the electronic device is configured with a first sub-preset condition and a second sub-preset condition. The first sub-preset condition includes: correct format; the second sub-preset condition includes: correct conclusion. Based on this, for any domain question data in the domain reasoning dataset, the electronic device filters first candidate data according to the first sub-preset condition, further extracts domain reasoning conclusion data from the first candidate data, filters second candidate data according to the second sub-preset condition, and finally determines the target data based on the second candidate data.

[0104] Specifically, for scenarios where the domain inference conclusion data is a script, the electronic device first performs format validation on all domain inference data. For example, it checks whether the inference process is presented according to a fixed structure of "step number + logical deduction" and whether the inference conclusion data contains a preset separator (such as "result:"). Data with disordered format is filtered out to obtain the first candidate data. Then, for the domain inference conclusion data in the first candidate data, the domain-specific syntax checking tool (such as a script compiler in the EDA field or a formula validator in the financial field) is used to verify its syntax compliance. Data with syntax errors (such as misspelled commands or missing parameters) is removed to obtain the second candidate data. Finally, the target data is determined from the second candidate data.

[0105] It should be understood that for scenarios where the reasoning conclusion data is in other forms, electronic devices first perform format verification on the domain reasoning data according to the requirements of the corresponding scenario. Then, for the domain reasoning conclusion data in the first candidate data, the correctness of the conclusion is verified by professional verification tools or rule bases in the corresponding scenario. Data that does not conform to the domain facts or has logical contradictions is eliminated to obtain the second candidate data.

[0106] It should be understood that the first candidate data, the second candidate data, and the target data all include domain reasoning process data and corresponding domain reasoning conclusion data.

[0107] It should be understood that the configuration of the first and second sub-preset conditions is specifically related to the target domain. For example, in the EDA domain, since the core is to generate executable electronic design scripts, the first sub-preset condition can be set as "the script must contain fixed paragraph structures such as module declarations, port definitions, and timing constraints". The second sub-preset condition checks whether the command statements (such as wiring commands and clock constraint commands) in the script conform to the tool's private syntax specifications by calling the syntax check interface of the EDA tool (that is, mainly checking whether the script content passes the syntax check). Therefore, this embodiment does not limit the specific content of the first preset condition, as long as it can reflect the basic requirements of the target domain for data format and syntax and ensure that the selected inference data has the basic characteristics of domain adaptability.

[0108] In the above process, the data structure is first standardized through format screening, providing a unified input format for subsequent syntax verification and model training; then, core errors are eliminated through syntax screening to ensure the basic validity of the domain inference conclusion data. The two screening steps are progressive, which improves screening efficiency while avoiding model learning bias caused by basic erroneous data entering the training process.

[0109] As another possible implementation, electronic devices can also simultaneously filter target data based on the first and second sub-preset conditions. They can also introduce a domain expert rule base for auxiliary filtering. That is, the machine first filters data that meets the format and syntax conditions, and then the domain experts manually mark data with rigorous reasoning logic and close to the actual scenario as target data based on their experience. This is suitable for niche fields with extremely high requirements for reasoning quality, and this embodiment does not limit it.

[0110] As a further optional design, in this embodiment, when the electronic device determines the target data based on the second candidate data, it first obtains the domain characteristic requirements, and then filters the target data from the second candidate data according to the domain characteristic requirements. The domain characteristic requirements include at least one of the following: the minimum number of inference steps required by the target domain, and the strictness level of the script syntax.

[0111] Specifically, the electronic device first collects characteristic parameters of the target domain, such as "the reasoning steps must be no less than 5 steps" and "the grammatical strictness is the highest level (no non-critical grammatical warnings are allowed)". Then, it traverses the second candidate data, counts the number of reasoning steps for each data, and eliminates data with insufficient steps. At the same time, according to the grammatical strictness level, the domain reasoning conclusion data is graded and verified (e.g., the basic level allows minor format warnings, while the strict level requires zero warnings). Finally, the target data that meets both the number of steps and grammatical strictness requirements is selected.

[0112] For example, in the EDA field, if the domain characteristic requirement is "the reasoning steps for complex chip routing tasks are no less than 8 steps" and "the script syntax is of industrial grade (it needs to pass full syntax verification by the tool)," then the electronic device will select the reasoning data from the second candidate data that includes at least 8 steps such as "requirement parsing → routing rule matching → conflict detection → path optimization → script generation", and the script is compiled by the EDA tool without any syntax errors or warnings as the target data.

[0113] By setting the above, the selected target data not only meets the basic format and syntax requirements, but also fits the professional characteristics of the target domain. This avoids logical breaks due to overly simplified reasoning steps, or scripts that cannot be executed in real-world scenarios due to insufficient syntax leniency, thereby further improving the domain adaptation accuracy of the current inference dataset.

[0114] As a further optional design, in this embodiment, when the electronic device determines the target data based on the second candidate data, it first obtains the demand information, and then filters the target data from the second candidate data according to the demand information. Here, user historical habits are used to indicate the domain reasoning conclusion data demand corresponding to historical domain problem data.

[0115] Specifically, electronic devices analyze users' historical interaction records to extract users' preference features for domain reasoning conclusion data, such as "preferring concise descriptions of reasoning processes" and "requiring reasoning conclusion data to include visual parameter charts." At the same time, they collect current user's explicit needs (such as "prioritizing the output of scripts that conform to a certain type of tool format"), and then select the data with the highest matching degree between historical preferences and current needs from the second candidate data as the target data.

[0116] For example, in the EDA field, if historical data shows that a user is accustomed to using "Verilog syntax" instead of "VHDL syntax" to write scripts, and the current requirement is "to generate inference results that include a timing analysis report", then the electronic device will select the inference data that uses Verilog syntax, includes timing analysis steps in the inference process, and includes a report generation command with the inference conclusion data from the second candidate data as the target data.

[0117] By setting the above parameters, the target data can be made more closely aligned with the user's actual usage habits and personalized needs, thereby improving the practicality of the model output and user acceptance, especially suitable for scenarios requiring human-machine collaboration.

[0118] In practical applications, electronic devices can also determine target data based on the aforementioned domain characteristics and requirements information, and can also combine the generation efficiency of inference data (such as filtering data with shorter processing time) or resource consumption (such as the computing power requirements when executing scripts) for comprehensive filtering. This embodiment does not limit this.

[0119] The method provided in this embodiment generates domain reasoning data containing reasoning processes and answers by inputting domain problem data into the current intermediate model. Then, it filters out target data with correct format and correct conclusions to update the preset reasoning dataset. This not only breaks through the bottleneck of scarce data in closed domains by leveraging the model's autonomous generation capability and realizes dynamic expansion of the dataset, but also ensures the adaptability of new data to domain rules through basic specification filtering, avoiding interference from erroneous data in model training. At the same time, the generation process can cover diverse reasoning paths, while the filtering stage ensures core effectiveness. Ultimately, it provides the model iteration with "sufficient quantity and high quality" training data that fits the actual needs of the domain, promoting the improvement of the domain reasoning model in terms of reasoning accuracy, rule compliance, and scenario adaptability, effectively balancing the model's generalization ability and domain specificity.

[0120] As can be seen from the foregoing, this embodiment generates domain inference data and obtains target data through multi-dimensional filtering, thereby achieving targeted expansion of the current inference dataset. This not only ensures the format standardization and grammatical validity of the newly added data, but also improves the data quality by adapting to domain characteristics and user needs, providing high-quality domain-specific data support for subsequent iterative training. This, in turn, promotes the optimization of the domain inference model's inference capabilities towards a more accurate and realistic direction.

[0121] As a detailed explanation, Figure 4 A flowchart illustrating a method for training a domain reasoning model provided in this application embodiment. Figure 3 This embodiment, based on the foregoing embodiments, provides a detailed description of the process for obtaining a preset inference dataset. For example... Figure 4 As shown, the method in this embodiment includes:

[0122] S401 collects a problem dataset that meets the second preset conditions from general open source data.

[0123] The second preset condition includes at least one of the following: belonging to the mathematical or code domain and containing keywords used to indicate multi-step reasoning, and having the same logical type as the target domain; wherein the logical type includes step-by-step decision-making, constraint verification, or multivariate optimization.

[0124] This setup allows for the precise selection of questions with complex reasoning attributes from general open-source data, ensuring a high degree of match between the question dataset and the logical reasoning requirements of the target domain. The mathematical and coding domains naturally contain multi-step derivation features, and their question data can provide a structured reasoning paradigm for the model. Furthermore, the constraint of the same logical type further guarantees the data's transferability and adaptability, laying the foundation for generating high-quality reasoning data subsequently.

[0125] S402, the problem dataset is processed using an inference model to generate inference data corresponding to each problem data in the problem dataset, and a preset inference dataset is formed based on the problem data and the inference data.

[0126] Among them, the reasoning process data is a long thought chain containing logical steps.

[0127] In this embodiment, 1000 high-quality math and code-related questions are collected from a general open-source dataset to form a question dataset. Then, an inference model is used to distill the inference data for each question in the question dataset. The inference data includes inference process data and inference conclusion data. In this embodiment, the inference process data specifically refers to long thought chains. The electronic device uses each question and its corresponding inference data as the initial, preset inference dataset.

[0128] It should be understood that a long thought chain specifically refers to a description of a reasoning process that includes complete steps such as "problem decomposition → condition analysis → step derivation → conclusion verification". For example, when solving a math problem, it is necessary to list out each step of the logic in detail, such as "transformation of known conditions → formula selection → substitution calculation → result verification".

[0129] It should be understood that inference models possess strong logical decomposition capabilities, enabling them to deduce complex problems step-by-step and output interpretable reasoning paths. High-quality problem data refers to problems with clear objectives, multiple constraints, and requiring multi-step derivation (such as "solving differential equations with multiple variables" or "writing nested loop code that satisfies specific functions"). This type of data can effectively stimulate the model's reasoning ability.

[0130] Furthermore, this embodiment selects data from the mathematical or code domains. Since both rely on strict logical chains and step-by-step derivations, they are highly similar to the reasoning patterns of closed domains (such as the wiring rule derivation in EDA), thus enabling cross-domain transfer of reasoning capabilities.

[0131] Furthermore, the electronic device uses this preset inference model to fine-tune the pre-trained original domain model, obtaining an intermediate model capable of outputting long thought chains. Specifically, for each training sample in the preset inference dataset, question data and inference data are separated; the inference data includes inference process data and inference conclusion data; using question data as input and inference data as the target output, the original domain model is fine-tuned to obtain the intermediate model; wherein, during fine-tuning, the loss weight of the inference process data is made higher than the loss weight of the inference conclusion data.

[0132] More specifically, in this embodiment, the fine-tuning objective is to minimize the negative log-likelihood loss function; wherein, the negative log-likelihood loss function... Represented as: ,in, For the t-th inference data, For the i-th question data, Given the problem data and model parameters θ, the model predicts... The probability of.

[0133] In this embodiment, the electronic device first splits each training sample into "question data" and "reasoning data (including process and answer)". The question data is used as the model input, and the reasoning data is used as the expected output for training. By setting a higher loss weight for the reasoning process data (e.g., process weight is 0.7, and answer weight is 0.3), the model pays more attention to the logic and completeness of the reasoning steps during learning. The negative log-likelihood loss function quantifies the deviation between the model's predicted reasoning data (especially process data) and the target data, guiding the iterative optimization of the model parameters θ, and ultimately enabling the model to generate an output that highly matches the target reasoning chain.

[0134] By implementing the above settings, the original domain model can be enhanced to learn the reasoning process, enabling it not only to output correct results but also to master the derivation logic. This gives it the ability to generate long thought chains that conform to domain rules, laying the foundation for handling complex reasoning tasks in closed domains.

[0135] In practical applications, fine-tuning can also be achieved without minimizing the negative log-likelihood loss function. For example, the cross-entropy loss function (suitable for classification reasoning steps) can be used, or a contrastive loss function can be introduced (optimizing the model by comparing the differences between high-quality and low-quality reasoning chains). Domain-specific rule losses (such as penalizing content that violates domain constraints in reasoning steps) can also be combined. The specific choice depends on the reasoning characteristics of the target domain, and this embodiment does not limit this.

[0136] The method provided in this embodiment ensures that the initial data has a logical foundation for domain-appropriate reasoning by selectively filtering high-quality questions from general data. Furthermore, it utilizes a reasoning model to generate reasoning data containing long thought chains, constructing a high-quality pre-set reasoning dataset. Weighted loss fine-tuning enables the original domain model to master the ability to output long thought chains. This overall process not only solves the problem of scarce initial reasoning data in closed domains but also enhances the learning process of reasoning, enabling the model to possess interpretable complex reasoning capabilities, providing core support for subsequent domain adaptation iterations.

[0137] As a detailed explanation of the training method for the domain reasoning model in this application, Figure 5 This is a schematic diagram illustrating the process of training a domain reasoning model according to an embodiment of this application, as shown below. Figure 5 As shown in this application, the electronic device first collects a problem dataset that meets the second preset condition from general open source data, then processes the problem dataset using an inference model to generate inference data corresponding to each problem data in the problem dataset, and constructs an initial preset inference dataset based on the problem data and the inference data.

[0138] Furthermore, the electronic device samples the domain problem data within the domain problem dataset based on the intermediate model to obtain corresponding domain inference data. It then combines the domain problem data and the domain inference data to update the preset inference dataset, obtaining the current inference dataset used in the first iteration. Next, the electronic device fine-tunes the pre-trained original domain model based on this current inference data to obtain the current intermediate model.

[0139] Next, as Figure 5As shown, the electronic device begins iterative training based on the current intermediate model and the current inference dataset, using the pre-trained original domain model as a foundation. Specifically, in each iteration, after fine-tuning the pre-trained original domain model based on the current inference dataset, it samples various domain question data from the domain question dataset using the current intermediate model to obtain corresponding domain inference data. This domain inference data is then further filtered to obtain target data. Finally, the current inference dataset is updated based on the target data and used as the current inference dataset for the next iteration. Furthermore, it should be noted that each iteration is based on the original domain model, combined with the current inference dataset for training.

[0140] Finally, when the iteration termination condition is reached, the intermediate model obtained from the last iteration is used as the final domain inference model.

[0141] Understandably, the above process constructs a positive cycle of "data quality improvement → model capability optimization": In the initial stage, the pre-set inference dataset generated by the inference model not only solves the problem of scarce initial data in the closed domain by using general data, but also injects basic inference capabilities into the model by filtering data that matches the logic of the target domain (such as multi-step inference data in the fields of mathematics and code); In subsequent iterations, the inference data generated by the current intermediate model based on the domain problem dataset is continuously filtered and focused on domain-specific rules (such as conforming to format and syntax standards), so that the domain adaptability of the current inference dataset is continuously improved, thereby driving the model to gradually master the domain-specific inference logic during training, and finally achieving optimization of inference accuracy and rule compliance.

[0142] In the above process, each iteration is trained based on the original domain model, which effectively avoids the accumulation of biases in the model during iteration. Specifically, the original domain model has pre-learned the basic rules and knowledge of the target domain. Iterating based on this ensures that each training iteration is anchored to the core framework of the domain knowledge, preventing the model from deviating from the essential rules of the domain due to data noise or local optima in multiple iterations, thus guaranteeing the stability of the training process and the correctness of the convergence direction.

[0143] This application also provides an embodiment of a method for using a domain reasoning model, which is executed by any electronic device. It should be understood that the executing entity of the method here may be the same electronic device as the executing entity of the aforementioned training method, or it may be a different electronic device. This application does not limit this. Figure 6 This is a flowchart illustrating a method for using a domain reasoning model provided in an embodiment of this application. Figure 6 As shown, the method in this embodiment includes:

[0144] S601, input the domain question-answering data of the target domain into the domain reasoning model trained by the aforementioned domain reasoning model training method to obtain domain reasoning data.

[0145] Among them, the domain question-and-answer data is the task feature information used to trigger the preset task in the target domain, and the domain reasoning data includes the domain reasoning process data and the domain reasoning conclusion data corresponding to the domain question-and-answer data.

[0146] S602, extract domain reasoning conclusion data from domain reasoning data, and determine the executable solution for the target domain based on the domain reasoning conclusion data.

[0147] The executable scheme conforms to the proprietary rules and technical specifications of the target domain.

[0148] Specifically, the electronic device first receives domain question-and-answer data (i.e., task requirements or problems to be solved) input by the user in the target domain, and inputs it into the domain reasoning model obtained by the aforementioned training method; the domain reasoning model outputs domain reasoning data containing the complete derivation process (domain reasoning process data) and the final result (domain reasoning conclusion data) based on the domain knowledge and reasoning logic learned during training; the electronic device extracts the domain reasoning conclusion data from the reasoning data, verifies its effectiveness in combination with domain-specific rules, and generates a solution that can be directly implemented.

[0149] Understandably, due to differences in task characteristics and knowledge systems across different fields, the corresponding domain data formats and contents vary: In the financial risk control field, domain question-and-answer data might be "a customer's loan application information and risk indicators," domain reasoning process data might be "the steps for calculating a customer's credit score and the logic for assessing repayment ability," and domain reasoning conclusion data might be "loan approval results and risk control recommendation reports." In the medical diagnosis field, domain question-and-answer data might be "patient symptoms, examination indicators, and medical history information," domain reasoning process data might be "the steps for analyzing symptoms to match disease types and the logic for deriving medication plans," and domain reasoning conclusion data might be "diagnostic conclusions and treatment plans." All of these data must conform to the professional terminology, process specifications, and output format requirements of their respective fields.

[0150] For example, the target domain is the EDA domain, the domain question-and-answer data is electronic design requirement data, the domain reasoning process data is the design logic derivation steps, the domain reasoning conclusion data is electronic design script data, and the executable solution is an electronic design solution that conforms to the EDA tool syntax.

[0151] The method provided in this embodiment obtains domain inference data containing the inference process and results by inputting domain question-and-answer data into a trained domain inference model, and then generates an executable solution based on the domain inference conclusion data, thus realizing the automated transformation from task requirements to implementation solutions. Because the domain inference model in this embodiment is trained with domain-specific data, the output inference data strictly follows domain-specific rules (such as EDA script syntax and financial risk control indicators), ensuring the accuracy and validity of the domain inference conclusion data. Simultaneously, the output format, which includes inference process data, enhances the interpretability of the solution, facilitating user traceability of logic and verification of rationality. Furthermore, the automated process reduces the cost and error of manual intervention, especially in closed domains (such as chip design and industrial control), enabling efficient response to professional task requirements and improving the efficiency and reliability of task execution within the domain.

[0152] The above embodiments introduce a method for training a domain reasoning model and a method for using a domain reasoning model from the perspective of process flow. The following embodiments introduce a training device for a domain reasoning model and a device for using a domain reasoning model from the perspective of virtual modules or virtual units. For details, please refer to the following embodiments.

[0153] This application provides a training device for a domain reasoning model. Figure 7 A schematic diagram of the structure of a training device for a domain reasoning model provided in an embodiment of this application is shown below. Figure 7 As shown, the device includes:

[0154] The fine-tuning module 71 is used to fine-tune the original domain model based on a preset inference dataset to obtain an intermediate model with inference capabilities. The preset inference dataset is generated by inferring general open-source data through the inference model and includes inference process data and inference conclusion data that conform to the output form of the target domain.

[0155] Training module 72 is used to iteratively train the original domain model based on the current inference dataset until the iteration termination condition is met to obtain the domain inference model of the target domain. In each iteration, the current inference dataset is updated based on the domain problem dataset of the target domain and the current intermediate model obtained based on the current inference dataset in the current iteration. The domain problem dataset contains task feature information of the target domain.

[0156] In another possible implementation of this application embodiment, the training module 72 is specifically used for:

[0157] Each domain problem data in the domain problem dataset is input into the current intermediate model to generate corresponding domain inference data; the domain inference data includes domain inference process data and domain inference conclusion data.

[0158] Select target data that meets the first preset condition from the reasoning data of each domain, and update the current reasoning dataset according to the target data and the corresponding domain question data; the first preset condition includes at least one of the following: correct format, correct conclusion.

[0159] In another possible implementation of this application embodiment, the training module 72 is specifically used for:

[0160] For each domain problem data in the domain problem dataset, the current intermediate model is controlled to perform a preset number of samplings at a preset output temperature to generate a corresponding preset number of domain inference data.

[0161] In another possible implementation of this embodiment, the training module 72 is specifically used for:

[0162] For any domain of problem data, the first candidate data is selected based on the first sub-preset condition; the first sub-preset condition includes: correct format;

[0163] Extract the domain reasoning conclusion data from the first candidate data, and filter the second candidate data according to the second sub-preset condition; the second sub-preset condition includes: the conclusion is correct;

[0164] The target data is determined based on the second candidate data.

[0165] In another possible implementation of this embodiment, the training module 72 is specifically used for:

[0166] Obtain the domain characteristic requirements; the domain characteristic requirements include at least one of the following: the minimum number of reasoning steps required by the target domain, and the strictness level of the script syntax;

[0167] Target data is selected from the second candidate data based on the characteristics and requirements of the domain.

[0168] In another possible implementation of this application embodiment, the training module 72 is specifically used for:

[0169] Obtain requirement information; requirement information includes at least one of the following: user history habits, user requirements; wherein, user history habits are used to indicate the domain reasoning conclusion data requirements corresponding to historical domain problem data;

[0170] Target data is selected from the second candidate data based on the demand information.

[0171] In another possible implementation of this embodiment, the training module 72 is further used for:

[0172] In each iteration, the current intermediate model is obtained by fine-tuning the original domain model based on the current inference dataset. In the first iteration, the current inference dataset is obtained by updating the preset inference dataset using the domain problem dataset and the intermediate model.

[0173] In another possible implementation of this application embodiment, the fine-tuning module 71 is further used for:

[0174] Collect a dataset of questions that meet the second preset conditions from general open-source data;

[0175] The problem dataset is processed using an inference model to generate inference data corresponding to each problem data in the problem dataset, and a pre-defined inference dataset is formed based on the problem data and the inference data; among them, the inference process data is a long thought chain containing logical steps.

[0176] Another possible implementation of this application embodiment includes a second preset condition that includes at least one of the following: belonging to the mathematical or code domain and containing keywords for indicating multi-step reasoning, and having the same logical type as the target domain; wherein the logical type includes step-by-step decision-making, constraint verification, or multivariate optimization.

[0177] In another possible implementation of this application embodiment, the fine-tuning module 71 is specifically used for:

[0178] For each training sample in the pre-defined inference dataset, the question data and inference data are separated; the inference data includes inference process data and inference conclusion data.

[0179] Using problem data as input and inference data as target output, the original domain model is fine-tuned to obtain an intermediate model; during fine-tuning, the loss weight of the inference process data is made higher than the loss weight of the inference conclusion data.

[0180] In another possible implementation of this application, when the target domain is electronic design automation (EDA), the domain problem data input to the domain inference model is electronic design requirement data, and the output domain inference data is design inference process data and domain inference conclusion data is electronic design script data. The electronic design script data is used to obtain an electronic design solution.

[0181] The application provides a training device for a domain reasoning model, which is applicable to the above-described training method for the domain reasoning model, and will not be described again here.

[0182] This application provides an apparatus for using a domain reasoning model. Figure 8 A schematic diagram of the structure of a device for using a domain reasoning model provided in an embodiment of this application is shown below. Figure 8As shown, the device includes:

[0183] Input module 81 is used to input domain question-answering data of the target domain into the domain reasoning model trained by any of the methods in the aforementioned training method embodiments to obtain domain reasoning data; the domain question-answering data is task feature information used to trigger a preset task in the target domain, and the domain reasoning data includes domain reasoning process data and domain reasoning conclusion data corresponding to the domain question-answering data;

[0184] The determination module 82 is used to extract domain reasoning conclusion data from the domain reasoning data and determine the executable solution of the target domain based on the domain reasoning conclusion data; the executable solution conforms to the proprietary rules and technical specifications of the target domain.

[0185] Another possible implementation of this application's embodiments is in the field of electronic design automation (EDA). The domain question-and-answer data is electronic design requirement data, the domain reasoning process data is design logic derivation steps, the domain reasoning conclusion data is electronic design script data, and the executable scheme is an electronic design scheme that conforms to the syntax of EDA tools.

[0186] The application provides a device for using a domain reasoning model, which is applicable to the above-described method for using a domain reasoning model, and will not be described again here.

[0187] This application provides an electronic device. Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, Figure 9 The illustrated electronic device includes a processor 91 and a memory 92. The processor 91 and the memory 92 are connected, for example, via a bus 93. Optionally, the electronic device may also include a transceiver 94. It should be noted that in practical applications, the transceiver 94 is not limited to one type, and the structure of this electronic device does not constitute a limitation on the embodiments of this application.

[0188] Processor 91 may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 91 may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0189] Bus 93 may include a pathway for transmitting information between the aforementioned components. Bus 93 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 93 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus 93 is represented by only one thick line, but this does not mean that there is only one bus 93 or one type of bus 93.

[0190] The memory 92 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0191] The memory 92 stores computer execution instructions for implementing the present application's solution, and its execution is controlled by the processor 91. The processor 91 executes the computer execution instructions stored in the memory 92 to implement the content shown in the foregoing method embodiments.

[0192] This application also provides a computer-readable storage medium, which may include various media capable of executing computer instructions, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores computer-executable instructions, which are used to implement the methods in the above embodiments.

[0193] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0194] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0195] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for training a domain reasoning model, the method comprising: The method comprises: Fine-tuning the original domain model based on a preset inference data set to obtain an intermediate model with inference capability; the preset inference data set is generated by performing inference on general open source data by an inference model and contains inference process data and inference conclusion data conforming to the output form of the target domain; Based on the current inference data set, iteratively train based on the original domain model until the iteration termination condition is reached to obtain the domain inference model of the target domain; wherein, in each iteration process, based on the domain problem data set of the target domain and the current intermediate model obtained based on the current inference data set in the current iteration process, the current inference data set is updated; the domain problem data set contains task feature information of the target domain.

2. The method of claim 1, wherein, The method further comprises: Inputting each domain problem data in the domain problem data set into the current intermediate model to generate corresponding domain inference data; the domain inference data includes domain inference process data and domain inference conclusion data; Filtering target data conforming to a first preset condition from each domain inference data, and updating the current inference data set according to the target data and the corresponding domain problem data; the first preset condition includes at least one of the following: correct format, correct conclusion.

3. The method of claim 2, wherein, The method further comprises: For each domain problem data in the domain problem data set, control the current intermediate model to sample at a preset output temperature for a preset number of times to generate a preset number of domain inference data.

4. The method according to claim 2 or 3, characterized in that, The method further comprises: For any domain problem data, filter first candidate data according to a first sub-preset condition; the first sub-preset condition includes: correct format; Extract the domain inference conclusion data in the first candidate data, and filter second candidate data according to a second sub-preset condition; the second sub-preset condition includes: correct conclusion; Determine the target data according to the second candidate data.

5. The method of claim 4, wherein, The method further comprises: Obtain domain characteristic requirements; the domain characteristic requirements include at least one of the following: the minimum number of inference steps required by the target domain, the strictness level of the script syntax, etc. Filter the target data from the second candidate data according to the domain characteristic requirements.

6. The method of claim 4, wherein, The method further comprises: Obtain requirement information; the requirement information includes at least one of the following: user historical habits, user requirements; wherein, the user historical habits are used to indicate the requirement of the domain inference conclusion data corresponding to the historical domain problem data; Filter the target data from the second candidate data according to the requirement information.

7. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: In each iteration process, based on the current inference dataset, the original domain model is fine-tuned to obtain the current intermediate model; wherein in the first iteration process, the current inference dataset is obtained by updating the preset inference dataset based on the domain problem dataset and the intermediate model.

8. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: Collecting a problem dataset conforming to a second preset condition from general open source data; Processing the problem dataset using the inference model to generate inference data corresponding to each problem data in the problem dataset, and forming the preset inference dataset based on the problem data and the inference data; wherein the inference process data is a long thinking chain containing logical steps.

9. The method of claim 8, wherein, The second preset condition comprises at least one of the following: belonging to a mathematical or code domain and containing keywords for indicating multi-step reasoning, and having the same logical type as the target domain; wherein the logical type comprises step-by-step decision, constraint condition verification, or multi-variable optimization.

10. The method according to any one of claims 1 to 3, characterized in that, The fine-tuning of the original domain model based on the preset inference dataset to obtain an intermediate model with reasoning capability comprises: For each training sample in the preset inference dataset, separate the problem data and the inference data; the inference data comprises inference process data and inference conclusion data; Fine-tune the original domain model with the problem data as input and the inference data as target output to obtain the intermediate model; wherein the loss weight of the inference process data is higher than that of the inference conclusion data during fine-tuning.

11. The method according to any one of claims 1 to 3, characterized in that, When the target domain is the electronic design automation (EDA) domain, the domain problem data input to the domain reasoning model is electronic design requirement data, the domain inference data output is design reasoning process data, and the domain inference conclusion data is electronic design script data, which is used to obtain an electronic design scheme.

12. A method of using a domain reasoning model, the method comprising: receiving a query; and providing a response to the query based on the domain reasoning model. The method comprises: Inputting the domain question and answer data of the target domain into the domain reasoning model trained by the method of any one of claims 1-11 to obtain domain inference data; the domain question and answer data is task feature information for triggering a preset task in the target domain, and the domain inference data comprises domain reasoning process data and domain reasoning conclusion data corresponding to the domain question and answer data; Extract the domain reasoning conclusion data from the domain inference data, and determine an executable scheme of the target domain according to the domain reasoning conclusion data; the executable scheme conforms to the special rules and technical specifications of the target domain.

13. The method of claim 12, wherein, The target domain is the electronic design automation (EDA) domain, the domain question and answer data is electronic design requirement data, the domain reasoning process data is a design logic derivation step, the domain reasoning conclusion data is electronic design script data, and the executable scheme is an electronic design scheme conforming to the syntax of an EDA tool.

14. A domain reasoning model training apparatus, comprising: The device comprises: The fine-tuning module is configured to fine-tune the original domain model based on a preset inference data set to obtain an intermediate model with inference capability; the preset inference data set is generated by performing inference on general open source data by using an inference model, and contains inference process data and inference conclusion data conforming to an output form of the target domain; The training module is configured to perform iterative training based on the current inference data set and the original domain model until a domain inference model of the target domain is obtained when an iteration termination condition is reached; in each iteration process, the current inference data set is updated based on a domain problem data set of the target domain and a current intermediate model obtained based on the current inference data set in the current iteration process; the domain problem data set contains task feature information of the target domain.

15. A domain reasoning model using apparatus, characterized by comprising: The device comprises: The input module is configured to input domain question and answer data of the target domain into the domain inference model trained by the method of any one of claims 1-11 to obtain domain inference data; the domain question and answer data is task feature information used to trigger a preset task of the target domain, and the domain inference data includes domain inference process data and domain inference conclusion data corresponding to the domain question and answer data; The determination module is configured to extract the domain inference conclusion data from the domain inference data and determine an executable scheme of the target domain according to the domain inference conclusion data; the executable scheme conforms to specific rules and technical specifications of the target domain.

16. An electronic device, comprising: Comprise: At least one processor and a memory; The memory stores computer execution instructions; The at least one processor executes the computer execution instructions stored in the memory, so that the at least one processor executes the method of any one of claims 1 to 13.

17. A computer readable storage medium characterized by: The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the central processing unit to implement the method of any one of claims 1 to 13.

18. A computer program product, characterised in that, The computer program is executed by the processor to implement the method of any one of claims 1 to 13. The computer program is executed by the processor to implement the method of any one of claims 1 to 13.

Images