Cross-domain tree model training method and cross-domain fusion prediction method and device

Abstract

The embodiment of the application provides a cross-domain tree model training method, a cross-domain fusion prediction method and device, the cross-domain fusion prediction method comprises the following steps: receiving a first general model trained by a model provider based on a multi-task domain training set, wherein at least one decision tree takes a task domain identifier as an explicit classification feature and guides the formation of multiple task domain sub-paths; using a verification set of a target task domain to which a target partner belongs to perform lightweight fine-tuning on the first general model, so as to select a task domain sub-path with the highest prediction index from the multiple task domain sub-paths and obtain a second general model; weighting and fusing prediction scores output by the second general model and a local customized model based on the verification set to determine a target weighting fusion strategy; and sending the second general model, the local customized model and the target weighting fusion strategy to the model provider, so that the model provider provides a fusion prediction service for the target partner.

Description

Technical Field

[0001] This application relates to the field of joint modeling technology, and in particular to a cross-domain tree model training method, a cross-domain fusion prediction method and apparatus. Background Technology

[0002] In multi-party data collaboration scenarios, collaborating parties (Party A) typically need to leverage the capabilities of external technology providers (Party B) to build machine learning models for risk assessment, user segmentation, or event prediction without sharing the original data. To meet data compliance and privacy protection requirements, current practices generally adopt a localized modeling model that ensures data remains within its local domain. This means that Party B provides the features or model capabilities, while Party A completes model training or inference in its local environment.

[0003] In cross-domain modeling scenarios involving structured data, tree models are often chosen as the final prediction model due to their advantages such as simple reasoning logic, low computational overhead, ease of deployment, strong interpretability, high efficiency in modeling structured data, and stable prediction performance. However, when faced with the need for knowledge reuse in cross-domain scenarios, tree models have obvious limitations. For example, their decision rules exist in the form of discrete tree structures, lacking a continuously differentiable parameter space, making it difficult to perform parameter transfer or fine-tuning through gradient backpropagation like neural networks.

[0004] While federated learning and transfer learning are frequently applied in cross-domain modeling scenarios, they also have certain drawbacks. For example, federated learning requires participants to frequently exchange gradients or intermediate statistics during training, which not only incurs high communication and computational overhead, but research also shows that such information can still leak sensitive data distributions through member inference or model inversion attacks, posing potential privacy risks. When transfer learning methods are applied to tree models, if an unsupervised alignment of feature distributions between the source and target domains is used, the transfer effect will be limited because it ignores the target domain label information. If the leaf node output values ​​are directly optimized based on the target domain loss function, the small sample size of the target domain makes it prone to overfitting, and the need for sequential adjustment node by node leads to low computational efficiency.

[0005] Therefore, under the premise of ensuring data security, how to improve the performance of local models by utilizing cross-domain external data remains a problem that current technology has not yet solved. Summary of the Invention

[0006] To achieve cross-task domain joint modeling while ensuring data security, this specification provides a cross-domain tree model training method, a cross-domain fusion prediction method, and an apparatus.

[0007] In a first aspect, embodiments of this application provide a cross-domain fusion prediction method based on a tree model, applied to a target partner. The method includes: receiving a first general model sent by a model provider, wherein the first general model is a gradient boosting decision tree model trained on a multi-task domain training set, wherein at least one decision tree uses task domain identifiers as explicit classification features and guides the formation of multiple task domain sub-paths; using a validation set of the target task domain to which the target partner belongs, performing lightweight fine-tuning on the first general model to obtain a second general model; wherein the lightweight fine-tuning is used to select the task domain sub-path with the highest prediction index from the multiple task domain sub-paths; performing weighted fusion of the prediction scores output by the second general model and the locally customized model based on the validation set to determine a target weighted fusion strategy; wherein the locally customized model is trained on the training set of the target task domain; and sending the second general model, the locally customized model, and the target weighted fusion strategy to the model provider so that the model provider can provide fusion prediction services for the target partner.

[0008] In an optional embodiment of this application, a second general model is obtained by lightweight fine-tuning the first general model using the validation set of the target task domain to which the target collaborator belongs. This includes: for each decision tree in the first general model, identifying multiple candidate task domain sub-paths guided by task domain identifiers as splitting features; calculating the prediction index of the multiple candidate task domain sub-paths on the validation set using the validation set of the target task domain to which the target collaborator belongs; selecting the task domain sub-path with the highest prediction index from the multiple candidate task domain sub-paths and masking the leaf node output values ​​of other task domain sub-paths to obtain the second general model.

[0009] In optional embodiments of this application, the prediction index includes at least one of the following: area under the receiver operating characteristic curve, KS statistic, or log-likelihood loss.

[0010] In an optional embodiment of this application, the weight value of the weighted fusion is a fixed weight; or, the weight value of the weighted fusion is a variable weight determined based on the optimization of the prediction index on the validation set.

[0011] In optional embodiments of this application, the locally customized model includes a scorecard model, a gradient boosting decision tree model, or a random forest model.

[0012] Secondly, embodiments of this application provide a cross-domain tree model training method, applied to a model provider. The method includes: acquiring a multi-task domain training set, wherein each sample in the multi-task domain training set includes a feature vector, a predicted label, and a corresponding task domain identifier; training a gradient boosting decision tree model based on the multi-task domain training set, wherein during the training process, the task domain identifier participates in the node splitting gain calculation of each round of the decision tree to obtain a decision tree that forms multiple task domain sub-paths guided by different task domain identifiers; and sending the trained gradient boosting decision tree model as a first general model to the target partner, so that the target partner can perform lightweight fine-tuning of the first general model based on the validation set of the target task domain.

[0013] In an optional embodiment of this application, training a gradient boosting decision tree model based on the multi-task domain training set includes: classifying each task domain identifier in the multi-task domain training set and introducing it as an explicit classification feature into the feature vector to form an enhanced feature vector; constructing a joint training set based on the enhanced feature vector and the predicted label; and training the gradient boosting decision tree model using the joint training set.

[0014] In an optional embodiment of this application, training a gradient boosting decision tree model using the joint training set includes: training the gradient boosting decision tree model on the joint training set using a lightweight gradient boosting machine algorithm or an extreme gradient boosting algorithm.

[0015] Thirdly, embodiments of this application provide a cross-domain fusion prediction method based on a tree model, applied to a model provider. The method includes: receiving a prediction request sent by a target partner, the prediction request including task data of a target task domain to which the target partner belongs; performing inference on the task data based on a pre-deployed second general model and a local customized model of the target partner to obtain corresponding prediction scores; wherein, the local customized model is trained based on the training set of the target task domain; the second general model is determined based on the target partner performing lightweight fine-tuning on a first general model provided by the model provider, and the tree model is further defined as follows: A general model is a gradient boosting decision tree model, wherein at least one decision tree includes internal nodes with task domain identifiers as splitting features; based on a target weighted fusion strategy, the predicted scores output by the second general model and the local customized model are weighted and fused to generate a fused predicted score; wherein the target weighted fusion strategy is determined by the target partner based on a validation set of the target task domain, after weighting and fusing the predicted scores output by the second general model and the local customized model; the fused predicted score is sent to the target partner so that the target partner can make task decisions for the target task domain based on the fused predicted score.

[0016] In an optional embodiment of this application, before receiving the prediction request sent by the target partner, the method further includes: receiving the second general model, the local customized model, and the target weighted fusion strategy of the two sent by the target partner; and deploying the second general model and the local customized model to provide fusion prediction services to the target partner.

[0017] Fourthly, embodiments of this application provide a cross-domain fusion prediction device based on a tree model, applied to a target partner. The device includes: a receiving module for receiving a first general model sent by a model provider, wherein the first general model is a gradient boosting decision tree model trained on a multi-task domain training set, wherein at least one decision tree uses task domain identifiers as explicit classification features and guides the formation of multiple task domain sub-paths; a processing module for performing lightweight fine-tuning on the first general model using a validation set of the target task domain to which the target partner belongs, to obtain a second general model; wherein the lightweight fine-tuning is used to select the task domain sub-path with the highest prediction index from the multiple task domain sub-paths; a fusion module for performing weighted fusion of the prediction scores output by the second general model and the local customized model based on the validation set to determine a target weighted fusion strategy; wherein the local customized model is trained on the training set of the target task domain; and an output module for sending the second general model, the local customized model, and the target weighted fusion strategy to the model provider, so that the model provider can provide fusion prediction services to the target partner.

[0018] Fifthly, embodiments of this application provide a tree model training device based on a multi-task domain, applied to a model provider. The device includes: an acquisition module for acquiring a multi-task domain training set, wherein each sample in the multi-task domain training set includes a feature vector, a predicted label, and a corresponding task domain identifier; a training module for training a gradient boosting decision tree model based on the multi-task domain training set, wherein during training, the task domain identifier participates in the node splitting gain calculation of each round of the decision tree to obtain a decision tree that forms multiple task domain sub-paths guided by different task domain identifiers; and an output module for sending the trained gradient boosting decision tree model as a first general model to the target partner, so that the target partner can perform lightweight fine-tuning of the first general model based on the validation set of the target task domain.

[0019] Sixthly, this application provides a cross-domain fusion prediction device based on a tree model, applied to a model provider. The device includes: a receiving module for receiving a prediction request sent by a target partner, the prediction request including task data of the target task domain to which the target partner belongs; and an inference module for inferring the task data based on a pre-deployed second general model and a local customized model of the target partner, respectively, to obtain corresponding prediction scores; wherein the local customized model is trained based on the training set of the target task domain; the second general model is determined based on the first general model provided by the model provider after the target partner performs lightweight fine-tuning, and the tree model is further defined as follows: A general model is a gradient boosting decision tree model, wherein at least one decision tree includes internal nodes with task domain identifiers as splitting features; a fusion module is used to perform weighted fusion of the prediction scores output by the second general model and the local customized model based on a target weighted fusion strategy to generate a fused prediction score; wherein the target weighted fusion strategy is determined by the target partner based on a validation set of the target task domain, after weighted fusion of the prediction scores output by the second general model and the local customized model; an output module is used to send the fused prediction score to the target partner, so that the target partner can make task decisions for the target task domain based on the fused prediction score.

[0020] In a seventh aspect, embodiments of this application provide an electronic device, which includes: a memory for storing a computer program product; and a processor for executing the computer program product stored in the memory, wherein when the computer program product is executed, the above-described method is implemented.

[0021] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed, implement the above-described method.

[0022] In summary, in the technical solution provided in this application, the model provider trains a general model based on a local cross-task domain training set. This enables the general model to possess general knowledge across multiple tasks. Furthermore, during training, the model provider introduces task domain identifiers as explicit classification features into the node splitting process of the gradient boosting decision tree, giving the trained general model inherent task awareness and path decision-making capabilities. After receiving the general model generated by the model provider, the target collaborator does not need to perform complex model retraining. It can adapt the general model to the local target task domain based on the local validation set, resulting in extremely low computational cost and processing difficulty. Moreover, there is no need for raw data interaction between the target collaborator and the model provider, which significantly improves the generalization performance of the cross-domain model while ensuring data privacy. Furthermore, by weightedly fusing the prediction scores of the fine-tuned general model and the local customized model, the target collaborator can effectively integrate cross-domain common knowledge with local specific cognition. After sending the fine-tuned general model, the local customized model, and the target fusion strategy between them to the model provider, the accuracy of the fusion prediction service provided by the model provider to the target collaborator during the inference phase can be greatly improved. Attached Figure Description

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

[0024] Figure 1a A flowchart illustrating a cross-domain tree model training method provided in this application embodiment.

[0025] Figure 1b This is a schematic diagram of a decision tree provided in an embodiment of this application.

[0026] Figure 2 A flowchart illustrating a cross-domain fusion prediction method based on a tree model, provided in an embodiment of this application.

[0027] Figure 3 A flowchart of another cross-domain fusion prediction method based on a tree model provided in this application embodiment.

[0028] Figure 4 This is an interaction signaling diagram between a model provider and a target partner, provided as an embodiment of this application.

[0029] Figure 5a This is a schematic diagram of the structure of a cross-domain fusion prediction device based on a tree model, provided in an embodiment of this application.

[0030] Figure 5b This is a schematic diagram of the structure of a tree model training device based on a multi-task domain, provided in an embodiment of this application.

[0031] Figure 5c This is a schematic diagram of another cross-domain fusion prediction device based on a tree model provided in an embodiment of this application.

[0032] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. Through these descriptions, the features and advantages of the embodiments of this application will become clearer and more apparent.

[0034] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0035] Furthermore, the technical features involved in the different implementations of the embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0036] With the rapid development of artificial intelligence (AI) technology, large language models (LLMs), also known as large models, have been applied to various fields. In practical applications, for a single domain, large models can be used for targeted data reasoning and services based on the characteristics of that domain. However, in multi-party collaborative scenarios, especially those involving cross-domain knowledge sharing, the models of each party are usually independently trained based on private data within their respective task domains. This results in the model's capabilities being limited to its local distribution, making it difficult to generalize to other task domains. Furthermore, due to restrictions related to data security and information protection regulations, the raw data of each party cannot be centralized across institutions in multi-party collaborative scenarios, thus forming "data silos."

[0037] For example, in collaborative scenarios between banks and e-commerce platforms (such as joint credit scoring, whitelist credit granting, scenario-based dynamic credit limit increases, anti-fraud and cash-out identification, personalized financial product recommendations, post-loan behavior monitoring and early warning, joint user lifecycle management, etc.), banks have users' credit records and transaction data, but not their e-commerce behavior data, while e-commerce platforms have users' consumption records, but not their repayment performance data.

[0038] In other words, in multi-party collaboration scenarios, data is fragmented among the parties, and any participant can only train a prediction model based on a local feature space and local label distribution. This can lead to problems such as incomplete data feature coverage, sample selection bias, increased concept drift, and inability to model cross features.

[0039] To address these challenges, the industry has explored various technological approaches to meet the collaborative modeling needs in multi-party scenarios. For example, a common approach is to deploy large models in the cloud and call them via Application Programming Interfaces (APIs) to enable cross-domain knowledge sharing among multiple parties. However, this method requires uploading each party's private data to a third-party server in the cloud for inference, posing a risk of privacy breaches and making it difficult to meet scenarios with high security requirements.

[0040] Therefore, to ensure data security, the industry has also tried other joint modeling methods. For example, federated learning (FL) can achieve joint training of models without sharing the original data. However, this method has huge communication overhead and poor support for mainstream non-neural network models in industry, such as gradient boosting decision trees (GBDT) and scorecards, making practical implementation difficult. Although using techniques such as transfer learning (TL) or full fine-tuning can improve model performance while keeping the data isolated from multiple parties, this method has certain requirements on the algorithmic capabilities and data scale of each party. It is prone to overfitting with small samples and cannot effectively integrate common knowledge across task domains.

[0041] Therefore, to address the aforementioned issues and the difficulty in federating tree models, which are the mainstream technology in industry, this application provides a cross-domain tree model training method and a cross-domain fusion prediction method based on tree models. The method provided in this embodiment supports model adaptation across multiple task domains and the fusion prediction of general models and locally customized models. It enables general knowledge sharing between multiple task domains and efficient fusion with the local characteristics of specific task domains. Furthermore, the method provided in this embodiment does not require the transmission of raw data by any party, which helps to ensure data privacy and compliance.

[0042] In this embodiment, the collaborating parties in the cross-domain collaboration scenario mainly include the model provider and the target collaborator. The model provider, as a technical service provider, can train a first general model with common knowledge across multiple task domains based on training sets from multiple different task domains. This model employs a gradient boosting decision tree structure and explicitly introduces task domain identifiers as splitting features during training, allowing the model to naturally form task domain sub-paths corresponding to each task domain, thus enabling flexible adaptation to any task domain subsequently.

[0043] Correspondingly, the target collaborator, as the executor of a specific task domain, can receive a first general model from the model provider. The target collaborator locally holds private data (including training and validation sets) for the target task domain. Based on this, upon receiving the first general model, the target collaborator can use its local validation set to perform lightweight fine-tuning, resulting in a second general model adapted to its own target task domain. In addition, the target collaborator also independently trains a locally customized model based on its local training set to capture data features unique to the target task domain. Thus, based on the local validation set, the target collaborator can determine the target weighted fusion strategy between the second general model and the locally customized model. Subsequently, the second general model, the locally customized model, and their target weighted fusion strategy are sent to the model provider, which performs fusion inference during the inference phase, providing fusion prediction services to the target collaborator.

[0044] Based on this, the application process of the various methods provided in the embodiments of this application in the above-mentioned cross-domain collaboration scenario will be described below with reference to the accompanying drawings.

[0045] Figure 1a This application illustrates a cross-domain tree model training method provided in an embodiment of the present application. This method is applied to a model provider to train a first general model with common knowledge across task domains.

[0046] Optionally, such as Figure 1a As shown, the training method for this cross-domain tree model includes: S102. Obtain the multi-task domain training set. Each sample in the multi-task domain training set includes a feature vector, a predicted label, and the corresponding task domain identifier. S104. Train a gradient boosting decision tree model based on a multi-task domain training set. During the training process, the task domain identifiers are involved in the node splitting gain calculation of each round of the decision tree to obtain a decision tree that is guided by different task domain identifiers to form multiple task domain sub-paths. S106. Send the trained gradient boosting decision tree model as the first general model to the target partner so that the target partner can perform lightweight fine-tuning of the first general model based on the validation set of the target task domain.

[0047] In this embodiment, the model provider, acting as a technical service provider, has long-term collaborative modeling efforts with multiple partners across different task domains. These partners may come from various heterogeneous industries, each with its own independent task domain objectives, user groups, and data distribution. Through past collaborations, the model provider has accumulated a large amount of historical data generated from interactions with these partners in its local secure environment. Although the specific application scenarios differ across task domains, the model provider can extract common data features across task domains by systematically analyzing this multi-source heterogeneous data. The specific types of these common data features are not limited; the common data features extracted from the historical data of each task domain will vary depending on the specific task domain.

[0048] Optionally, before extracting common data features, the model provider can first classify each task domain according to similarity, and then extract common data features from historical data of multiple task domains whose similarity meets preset requirements. For example, assuming that task domains such as e-commerce, consumer finance, and insurance are divided into one category based on similarity, the model provider can extract basic attribute features such as user basic information, behavior type, and device type from historical data of task domains such as e-commerce, consumer finance, and insurance; behavioral activity features such as login frequency, operation duration, and frequently accessed pages; and risk signal features such as abnormal logins, high-frequency transactions, and large-amount transfers as common data features.

[0049] Of course, the above common data characteristics are only illustrative examples. In practical applications, they are not limited to these. The specific data types extracted can be determined according to the actual situation, which will not be detailed here.

[0050] In practical applications, these common data features possess stable and transferable discriminative capabilities for the prediction target across multiple task domains. Therefore, based on the above insights, model providers can define historical data with common data features as samples from their locally stored historical data. They can then determine the feature vector for each sample, define prediction labels, and annotate the task domain identifier to which each sample belongs, thereby constructing a structured multi-task domain training set. This preserves the unique information of each task domain while integrating common knowledge across task domains.

[0051] Based on this, the model provider can train a multi-task domain joint gradient boosting decision tree model using this multi-task domain training set. During training, in order to adapt to different task domains, task domain identifiers are explicitly introduced into the input feature space and participate in the node split gain calculation of each decision tree. This enables the gradient boosting decision tree model to automatically learn differentiated decision paths for different task domains based on the task domain identifiers, resulting in decision trees that guide multiple task domain sub-paths with different task domain identifiers.

[0052] Alternatively, during training, the process of forming multiple task domain sub-paths based on task domain identifiers can be implemented using the following formula:

[0053] Among them, This indicates an indicator function that returns 1 if the condition is true, and 0 otherwise. This represents the feature vector of the input sample; Indicates the task domain identifier to which the sample belongs; and Represents the sample sets under two task domains; and They respectively represent the task domains and task domain A dedicated sub-model; This represents the prediction function for the final output.

[0054] Optionally, during the training of the gradient boosting decision tree model based on the multi-task domain training set, the model provider can first encode the category of each task domain identifier in the multi-task domain training set and introduce it as an explicit classification feature into the feature vector to form an enhanced feature vector. Then, a joint training set is constructed based on the enhanced feature vector and the predicted label, and the gradient boosting decision tree model is trained using this joint training set. The encoding method for the task domain identifier is not limited; optionally, it may include, but is not limited to, encoding the task domain identifier using integers, hash values, or embedding vectors.

[0055] Of course, the above is only an example. The specific encoding method can be determined according to actual needs, and will not be elaborated here. Alternatively, during training, to prevent overfitting, the depth of nodes that split using task domain identifiers as the splitting feature can be limited (e.g., splitting is only allowed in layers 2–4), while the original structure of parts that do not split using task domain identifiers is preserved. In addition, during training, the maximum depth of a single tree can be controlled (e.g., maximum depth ≤ 6) and the total number of iterations can be increased to maintain the overall expressive power of the gradient-boosting decision tree model.

[0056] Of course, the above training process is only an example. The specific training method can be determined according to actual needs, and will not be elaborated here.

[0057] After the above training, for a decision tree containing task domain identifiers as splitting nodes, internal nodes near the root can use common features to make general judgments, while deeper nodes split into multiple task domain sub-paths based on task domain identifiers. In this way, a gradient boosting decision tree model can simultaneously encode cross-domain generalization ability and task adaptation ability, improving the model's cross-task domain adaptability.

[0058] Assuming a fintech platform is the model provider, the training process of the gradient boosting decision tree model is as follows: In the stage of building a multi-task domain training set, the model provider first collects historical data from multiple partners. Then, it extracts common data features (such as user behavior type, device type, and transaction scenario) from the historical data and uses them as the feature vector of the sample. It defines prediction labels according to the prediction goals of each partner (such as "whether the repayment time is overdue") and marks the task domain identifier corresponding to each sample according to the source of each historical data (such as "A", "B" and "C" representing different task domain identifiers).

[0059] Furthermore, during the gradient boosting decision tree model training phase, the model provider encodes the task domain identifier as a category feature when training each decision tree, and incorporates the task domain identifier along with other task domain features into the node split gain calculation. Based on this, if it is determined that the task domain identifier can significantly improve the split gain (i.e., the decision logic of different task domains differs greatly), then the task domain identifier is determined as a split feature, and multiple sub-paths are split from the current node based on this split feature. Ultimately, a decision tree containing a structure of multiple task domain sub-paths guided by the task domain identifier is formed.

[0060] Based on this Figure 1b A schematic diagram of the structure of a decision tree is shown, such as... Figure 1b As shown, the "task domain identifier" serves as a splitting feature, guiding the formation of three task domain sub-paths. During model training, the node corresponding to the "task domain identifier" will divide the input samples according to the task domain, assigning samples belonging to different task domains to different task domain sub-paths. For example, samples belonging to "task domain A" are assigned to "leaf node 4", samples belonging to "task domain B" are assigned to the sub-path containing "node X3 - leaf node 6", and samples belonging to "task domain C" are assigned to "leaf node 5".

[0061] Similarly, each decision tree is trained according to the above process, and finally, the model provider can obtain a gradient boosting decision tree model containing multiple decision trees.

[0062] Furthermore, the model provider can send the trained gradient boosting decision tree model as the first general model to any target partner. The target partner can then perform lightweight fine-tuning of the first general model based on its local validation set. For example, it can select task domain sub-paths with satisfactory prediction performance from the first general model, or suppress or block task domain sub-paths that are irrelevant to its own target task domain, in order to obtain a second general model that is adapted to its local target task domain.

[0063] Therefore, it is evident that, for the model provider, training sets constructed based on historical data from different task domains can train gradient boosting decision tree models with strong generalization capabilities. Since the decision tree structure in this gradient boosting decision tree model includes internal nodes with task domain identifiers as splitting features, and multiple task domain sub-paths guided by these identifiers, the model possesses "built-in task domain awareness." This allows partners to adapt the model to the task domain at extremely low cost based on local task domain validation sets, without needing to retrain the model or transmit raw data to the model provider. This simplifies the process and meets data security requirements.

[0064] Compared to the traditional approach that requires training a separate model for each task domain, the first general model trained using the above method only splits nodes based on task domain identifiers where necessary. This allows different task domains to share the common features of the paths before that node, which not only significantly reduces model redundancy but also improves processing efficiency.

[0065] To more clearly explain the principles of the various methods provided in the embodiments of this application, the relevant terms involved in the embodiments of this application will be explained below.

[0066] In this application embodiment, a task domain refers to a set of application scenarios with the same modeling objective but different data distributions. Examples include credit risk assessment tasks for different financial institutions (banks, consumer finance companies), user behavior prediction tasks belonging to the same platform but for different regions (first-tier cities, lower-tier markets), and anti-fraud tasks in different industries (e-commerce, travel, gaming), etc. For instance, in the construction of a multi-task domain training set, each task domain has independent label definitions, feature distributions, and performance requirements, but they can share some common features such as user behavior types and device types.

[0067] For different task domains, this application embodiment pre-defines corresponding task domain identifiers. These identifiers can be understood as discrete meta-features used to distinguish the task domain to which a sample belongs. The representation is not specifically limited; optionally, the task domain identifier can be an integer, for example, "task_id" as the task domain identifier, where task_id = 3 indicates a specific task domain; or, the task domain identifier can also be a string, for example, "domain_id" as the task domain identifier, where domain_id = "MK" indicates a specific task domain.

[0068] Of course, the above is only an example. Depending on the processing requirements, the task domain identifier can also be selected in other forms, which will not be elaborated here.

[0069] In the constructed multi-task domain training set, samples belonging to different task domains correspond to different label distributions or model residuals. Therefore, the task domain identifier is explicitly introduced into the input feature space as a splitting feature. When participating in the construction of the decision tree, it can guide the formation of different task domain sub-paths at the current node based on sample differences. Each task domain sub-path refers to a path from the root node to a leaf node that contains internal nodes with the task domain identifier as the splitting condition, making the path effective only for samples of a specific task domain. For example, if a node splits according to domain_id = "MK", ​​then after the split, its left subtree can be dedicated to the "MK" task domain, while the right subtree is used to adapt to other task domains.

[0070] In this embodiment, the gradient boosting decision tree model is an ensemble learning method used to iteratively train multiple decision trees, enabling each tree to fit the residuals (negative gradients) of the preceding model. Finally, the sum of the output values ​​of the leaf nodes of all trees is used as the prediction result. The specific type of gradient boosting decision tree model is not limited, but may optionally include, but is not limited to, typical implementations such as extreme gradient boosting (XGBoost), lightweight gradient boosting machine (LightGBM), and category boosting (CatBoost) tree models.

[0071] Of course, the above is only an illustrative example. In practical applications, it is not limited to this. The specific tree model type can be selected according to actual needs, which will not be elaborated here.

[0072] In the decision tree construction process, the task domain identifier is treated as a general feature and participates in the calculation of the splitting criterion for each node. At each node split, the decision tree incorporates the task domain identifier into the candidate feature set and evaluates its splitting value by calculating the information gain (or the reduction in the loss function) brought about by splitting at different thresholds. When the sample differences are sufficiently large, splitting nodes according to the task domain identifier can significantly reduce the prediction errors of its left and right subtrees, thereby bringing high gains and improving the model's prediction performance, generalization ability, and interpretability.

[0073] Based on the above, this application also provides a cross-domain fusion prediction method based on a tree model. This method is applied to a target partner to perform lightweight fine-tuning on a first general model generated by a model provider, and to determine the target fusion strategy between a second general model and a local customized model. The details are described below.

[0074] Figure 2 This document illustrates a flowchart of a tree-based cross-domain fusion prediction method provided in an embodiment of this application. Figure 2 As shown, the method includes: S202. Receive the first general model sent by the model provider. The first general model is a gradient boosting decision tree model trained on a multi-task domain training set, wherein at least one decision tree uses the task domain identifier as an explicit classification feature and guides the formation of multiple task domain sub-paths. S204. Using the validation set of the target task domain to which the target partner belongs, the first general model is lightly fine-tuned to obtain the second general model; wherein, the lightly fine-tuning is used to select the task domain sub-path with the highest prediction index from multiple task domain sub-paths. S206. The predicted scores output by the second general model and the local customized model are weighted and fused based on the validation set to determine the target weighted fusion strategy; wherein, the local customized model is trained based on the training set of the target task domain; S208. Send the second general model, the local customized model, and the target weighted fusion strategy to the model provider so that the model provider can provide fusion prediction services to the target partner.

[0075] In this embodiment, the model provider trains a first general model based on historical data from multiple task domains accumulated locally. Although this model incorporates common cross-task domain knowledge (such as basic user attribute features, behavioral activity features, risk signal features, etc.), significant differences exist between task domains in label definitions, positive and negative sample ratios, feature importance ranking, and user group distribution. Therefore, the first general model cannot directly and accurately match the true data feature distribution of the target partner's target task domain. If the target partner directly uses the first general model for prediction tasks in the target task domain, its output may be interfered with by other unrelated task domain sub-paths, leading to prediction bias, decreased sensitivity, or prediction metrics failing to meet expectations. Especially for target task domains with unique application logic (e.g., e-commerce platforms focus on "return frequency," while banks focus on "debt repayment ratio"), the unadapted first general model cannot fully leverage its knowledge transfer value.

[0076] Therefore, in order to ensure that the target partner can effectively utilize the cross-task domain common knowledge accumulated by the model provider while ensuring that the prediction results closely match the real data distribution of its local target task domain, after receiving the first general model sent by the model provider, the target partner needs to use the validation set of its local target task domain to perform lightweight fine-tuning on the first general model to obtain the second general model.

[0077] Lightweight fine-tuning refers to the process by which the target collaborator selects the most effective prediction path for the target task domain from multiple preset task domain sub-paths without modifying the original tree structure and internal node splitting rules of the first general model, thereby achieving model adaptation. The process is explained below.

[0078] In this embodiment, since the task domain identifier has been explicitly introduced into the feature space and participates in splitting during the pre-training stage, each tree naturally contains several mutually exclusive or partially overlapping task domain-specific prediction branches. Based on this, for each decision tree in the first general model, the target collaborator first identifies all candidate task domain sub-paths formed by the task domain identifier as a splitting feature. Here, each candidate task domain sub-path refers to a complete path that starts from the root node, passes through one or more internal nodes with the task domain identifier as the judgment condition, and finally reaches a certain leaf node. Logically, each path is only effective for samples of a specific task domain (or a class of similar task domains).

[0079] Secondly, using the validation set of the target task domain held locally by the target partner, each of the above candidate task domain sub-paths is independently evaluated, and the prediction metrics of multiple candidate task domain sub-paths on the validation set are calculated respectively. Optionally, the validation set samples can be input into each decision tree in the first general model, but only the task domain sub-path to be evaluated in each decision tree is activated (i.e., the output values ​​of the leaf nodes corresponding to other task domain sub-paths are temporarily masked), while the other shared paths remain unchanged, thereby obtaining the prediction score of the currently evaluated task domain sub-path on the target task domain, and calculating its corresponding prediction metric accordingly.

[0080] Finally, for each decision tree, the task domain sub-path that performs best on the validation set (i.e., has the highest prediction index) is selected as its effective path in the target task domain, and the leaf node outputs of the other task domain sub-paths are permanently masked (e.g., their output values ​​are set to zero). After completing the path selection for all decision trees, a second general model adapted to the target task domain is obtained.

[0081] The specific type of predictive indicator is not limited, but optionally, the predictive indicator may include at least one of the following: Area Under the Receiver Operating Characteristic Curve (AUROC), Kolmogorov–Smirnov Statistic (KS), or Logarithmic Loss (LogLoss).

[0082] Of course, the above is only an illustrative example. In practical applications, it is not limited to this. The specific type can be determined according to actual needs, which will not be elaborated here.

[0083] In this embodiment, the task domain identifier corresponding to the task domain sub-path with the highest prediction index is not limited. Optionally, the task domain identifier corresponding to the task domain sub-path with the highest prediction index may be different from the task domain identifier of the target task domain. That is, when selecting a task domain sub-path, the task domain sub-path with the highest adaptability to the target task domain is selected, rather than simply selecting a task domain sub-path that corresponds exactly to the target task domain identifier.

[0084] This is because different task domains may possess semantic or distributional similarities. For example, e-commerce platform A and e-commerce platform B, though different partners, share highly similar user behavior patterns. Among multiple candidate task domain sub-paths, a sub-path outside the current target task domain might achieve better performance on the validation set of the target task domain due to higher historical data quality, more comprehensive feature representation, or a distribution closer to the current target task domain. Therefore, allowing and encouraging this cross-domain knowledge transfer—that is, selecting the sub-path with the "best prediction effect" rather than the "same label"—maximizes knowledge reuse efficiency.

[0085] For example, the target task domain is "E-commerce Risk Control A," and its task domain identifier is "AFK." In a decision tree of the first general model, there are three candidate task domain sub-paths, corresponding to task domain identifiers "AFK," "BFK," and "CFK," respectively. Suppose that during model fine-tuning, although a task domain sub-path with the identifier "AFK" exists, the "BFK" task domain sub-path is determined to have the highest AUROC after validation set evaluation. In this case, the target partner can select the "BFK" task domain sub-path as the valid path and disable the output values ​​of the corresponding task domain sub-paths for "AFK" and "CFK."

[0086] Through the aforementioned model fine-tuning process, the pre-trained first general model can be efficiently, safely, and with low overhead adapted to the locally held validation set of the target task domain. The resulting second general model retains the common risk patterns learned by the model provider in multiple scenarios while precisely focusing on the knowledge fragments with the most discriminative power for the current target task domain, possessing both the advantages of generalization and scenario sensitivity. Furthermore, this model fine-tuning process completely avoids gradient updates of leaf node values ​​or splitting thresholds in traditional fine-tuning, resulting in low computational cost, low risk of overfitting, and compliance with the "lightweight" requirement.

[0087] In this embodiment of the application, in addition to making lightweight fine-tuning to the first general model sent by the model provider, in order to make full use of the target partner's unique task domain data, feature system and label definition, the target partner can also build a local customized model that is highly adapted to the local target task domain to make up for the shortcomings of the second general model in terms of fine granularity and task domain specificity.

[0088] In this embodiment, the type of local custom model is not limited. Optionally, the local custom model includes, but is not limited to, a scorecard model, a gradient boosting decision tree model, or a random forest model (FR). The specific type can be selected according to actual needs, and will not be elaborated here.

[0089] It should be noted that the training method for locally customized models is not limited here; the training method can vary depending on the type of locally customized model. For example, the conventional training method for training corresponding models can be used for model training. The specific training process will not be detailed here.

[0090] It should be further noted that, for the locally customized model and the first general model, the model types can be the same or different, provided that the deployment requirements of the model provider are met. The specific type can be selected according to actual needs and is not limited here.

[0091] Based on this, in order for the model provider to perform fusion inference based on the second general model and the local customized model during the inference phase and determine the fusion prediction score that meets the requirements, after obtaining the second general model and the local customized model, the target partner can perform weighted fusion of the prediction scores output by the second general model and the local customized model based on the validation set to determine the target weighted fusion strategy.

[0092] In this embodiment, a target weighting strategy is used to determine the weight values ​​for the weighted fusion of the second general model and the local customized model. The specific form of the target weighting strategy is not limited. Optionally, the weight values ​​for weighted fusion can be directly preset, i.e., the weight values ​​are fixed. Alternatively, the weight values ​​can be determined based on optimizing the prediction metrics on the validation set, i.e., the weight values ​​are variable. In other words, the variable weights are determined after performance evaluation of the prediction scores of the second general model and the local customized model on the validation set. Since the validation set reflects the true data distribution of the target task domain, the variable weights determined based on the validation set can maximize the fusion prediction performance of the second general model and the local customized model.

[0093] In one optional embodiment, a fixed-weight strategy is adopted. The target partner can pre-set the fusion weights of the second general model and the local customized model based on prior experience or preset rules. These fusion weights remain unchanged throughout the inference process. For example, the weight of the second general model can be set to 0.6, and the weight of the local customized model can be set to 0.4, indicating greater trust in the cross-domain common knowledge contained in the second general model; or, in scenarios where local data is extremely sparse, the second general model can be given a higher weight, such as 0.8, to avoid overfitting of the local model. The advantages of adopting a fixed-weight strategy are its simplicity, high inference efficiency, and lack of need for additional validation data, making it suitable for deployment environments with high real-time requirements or where local validation sets are unavailable.

[0094] In one optional embodiment, a variable weight strategy is employed. The target partner uses its target task domain validation set to evaluate the performance of the second general model and the locally customized model, respectively, and dynamically optimizes the fusion weights based on the evaluation results to maximize overall prediction performance. Since the validation set truly reflects the data distribution and business characteristics of the target task domain, the variable weights determined in this way can adaptively balance the contributions of general knowledge and local characteristics, which helps improve the model's generalization ability in scenarios with sufficient data and sensitivity to accuracy.

[0095] For example, a set of candidate weight combinations can be traversed from 0.0 to 1.0 with a step size of 0.1. For each combination, the target index (such as AUROC, KS, or LogLoss) of the weighted fusion prediction result on the validation set can be calculated, and finally, the weight that optimizes the index is selected as the fusion parameter. Alternatively, continuous optimization methods (such as grid search, Bayesian optimization, or gradient approximation) can be used to solve for the optimal weights. Of course, the specific method can be selected according to actual needs and is not limited to these.

[0096] It should be noted that the two weighting strategies mentioned above are not mutually exclusive and can be used in combination in practice. For example, a fixed weight can be used in the early stages of model deployment to ensure stability, and then switched to a variable weight strategy to continuously optimize performance after accumulating sufficient local validation samples; or, different weighting strategies can be applied to different subsets of samples (such as new users and old users) to achieve fine-grained fusion.

[0097] Regardless of the weighting strategy adopted, by introducing two implementation methods, fixed weight and variable weight, it is possible not only to achieve lightweight, low-latency, and rapid deployment, but also to achieve high-performance fusion based on data-driven approaches and flexibly adapt to diverse cross-domain collaboration scenarios.

[0098] The following section provides an illustrative example of the process for determining the target weighted fusion strategy using a weighted fusion method, with specific formulas as examples.

[0099] In an optional approach, for the validation set under the target task domain The weight values ​​for weighted fusion can be determined using the following formula:

[0100] in, It is the preliminary score of each decision tree in the gradient boosting decision tree model. For the target task domain, a decision tree model is used. It is the set of all task domain partitions of a decision tree. The weight value is the weight for weighted fusion, and its value can be any number between 0 and 1.

[0101] In the actual training process of gradient boosting decision tree models, in order to fully explore the common data features among multiple task domains, a large number of task domain labels are usually introduced into the decision tree. This results in a large depth of the decision tree and a large number of learnable weights. This model structure not only poses the risk of overfitting in small sample scenarios, but also presents certain difficulties for model storage, deployment and inference.

[0102] To alleviate this problem, a sparsity mechanism can be introduced in the selection of weight values ​​to reduce the difficulty of adapting the model to the target task domain.

[0103] Based on this, in another alternative approach, for the validation set under the target task domain The weight values ​​for weighted fusion can be determined using the following formula:

[0104] Unlike the example above, the weight values ​​in this example... The value can be either 0 or 1, ensuring that only a few task domain sub-paths that are highly compatible with the target task domain receive non-zero weights, while the weights of the remaining task domain sub-paths are set to zero. This dilution mechanism not only reduces the computational complexity of the inference stage but also effectively suppresses noise interference from task domain sub-paths that are not compatible with the target task domain, further improving the accuracy of the fused prediction results and the deployment efficiency of the model.

[0105] Based on the above, after obtaining the second general model, the local customized model, and the target fusion strategy between the two, the target partner can send the second general model, the local customized model, and the target weighted fusion strategy to the model provider so that the model provider can provide fusion prediction services to the target partner.

[0106] Therefore, for the target collaborator, there is no need to access the model provider's original training data or retrain the model. The first general model can be adjusted to a second general model adapted to the local target task domain simply by selecting the structure and configuring the weights, which helps reduce computational overhead. Furthermore, without providing the model provider with local raw data, the second general model can accurately fit the local data distribution, contributing to improved prediction metrics. Moreover, based on the local validation set, a weighted fusion of the prediction scores of the second general model and the locally customized model not only integrates cross-domain common knowledge with local task domain features, but the resulting target fusion strategy also possesses both generalization ability and task domain sensitivity, greatly improving the accuracy of fusion predictions in the subsequent inference stage.

[0107] Based on this, this application also provides a cross-domain fusion prediction method based on a tree model. This method is applied to a model provider to provide fusion prediction services to a target partner based on a second general model, a local customized model, and a target fusion strategy of the two.

[0108] Figure 3 A flowchart of another tree-based cross-domain fusion prediction method is shown, such as... Figure 3 As shown, the method includes: S301. Receive a prediction request sent by the target partner. The prediction request includes task data of the target task domain to which the target partner belongs. S302. Based on the pre-deployed second general model and the target partner's local customized model, inference is performed on the task data to obtain the corresponding prediction scores; wherein, the local customized model is trained on the training set of the target task domain; the second general model is determined based on the target partner's lightweight fine-tuning of the first general model provided by the model provider, and the first general model is a gradient boosting decision tree model, wherein at least one decision tree includes internal nodes with task domain identifier as the splitting feature; S303. Based on the target weighted fusion strategy, the prediction scores output by the second general model and the local customized model are weighted and fused to generate a fused prediction score; wherein, the target weighted fusion strategy is determined by the target partner based on the validation set of the target task domain and after weighted fusion of the prediction scores output by the second general model and the local customized model. S304. Send the fusion prediction score to the target partner so that the target partner can make task decisions for the target task domain based on the fusion prediction score.

[0109] In this embodiment of the application, after receiving the second general model, the local customized model, and the target weighted fusion strategy of the two sent by the target partner, the model provider can deploy the second general model and the local customized model locally for use in the fusion prediction service for the target partner.

[0110] Therefore, when a target partner has a need for fusion prediction, they can send a prediction request to the model provider to deliver the task data required for the fusion prediction service. For example, the model provider can provide service interfaces to various partners, and each partner can send prediction requests to the model provider by calling its corresponding service interface. Based on this, when the model provider responds to a target partner's call to its corresponding service interface, it can receive the service request sent by the target partner and parse the task data sent by the target partner from the corresponding service request.

[0111] In this embodiment, the specific content of the task data sent by the target partner is not limited; the task data sent may differ depending on the type of prediction service requested. For example, taking a fintech platform as the model provider, it can provide a "credit risk prediction service" to the target partner. The basic input parameters required for this service are the user's basic information, such as, but not limited to, the user's job type, work address, and task type. Suppose that the target partner wants to assess whether a local user has credit risk; when initiating a prediction request to the model provider, it can send the user's job type, work address, and task type as task data, so that the model provider can use this task data as input parameters for the "credit risk prediction service" to predict whether the user has credit risk.

[0112] Of course, the above description of the types of prediction services and task data is only an example. In actual applications, it is not limited to this and can be determined according to actual needs, which will not be elaborated here.

[0113] Furthermore, after receiving the task data sent by the target partner, the model provider can perform inference on the task data based on a pre-deployed second general model and the target partner's local customized model to obtain corresponding prediction scores. Then, based on the target weighted fusion strategy obtained from the target partner, the model provider can weightedly fuse the prediction scores output by the second general model and the local customized model to generate a fused prediction score. Based on this, the model provider can send the fused prediction score to the target partner, allowing the target partner to make task decisions for the target task domain based on the fused prediction score. For example, in the above example, the generated fused prediction score is used as an indicator to measure whether a corresponding user has credit risk. After receiving the fused prediction score, if the target partner determines that the corresponding user has credit risk according to its local target task domain rules, it can implement measures such as access restrictions, risk warnings, and designated service recommendations for the corresponding user to reduce platform risk.

[0114] Therefore, based on the second general model obtained by the target partner after fine-tuning the first general model, the target partner's locally customized model, and the target fusion strategy between the two, the model provider can provide the target partner with a highly adaptable fusion prediction service for the target task domain during the inference stage without accessing the target partner's private data. This achieves a dual improvement in prediction accuracy and task domain adaptability while ensuring data security. Furthermore, the fusion prediction results not only inherit the cross-task domain common knowledge accumulated by the model provider but also fully reflect the target partner's local target task domain characteristics, truly realizing the synergistic gain of "breadth of knowledge" and "depth of insight".

[0115] To more clearly illustrate the implementation principle of the technical solution in this application, Figure 4 An interaction signaling diagram between the model provider and the target partner is shown to illustrate the overall implementation flow of the technical solution of this application. The following section combines... Figure 4 A brief explanation of the basic principles of the technical solution in this application is provided.

[0116] like Figure 4 As shown, during the model training phase, the model provider can construct a multi-task training set based on local historical data, and then train a first general model based on this multi-task training set. Simultaneously, the target partner can also train a locally customized model based on the local training set. Furthermore, as... Figure 4 As shown, the model provider can send the trained first general model to the target partner. After receiving the first general model, the target partner can perform lightweight fine-tuning on the first general model based on the local validation set to obtain a second general model adapted to the local target task domain.

[0117] Furthermore, in order to provide fusion prediction services to the target collaborator during the inference phase based on both general knowledge across task domains and specific features of the target task domain, such as... Figure 4 As shown, after obtaining the second general model, the target partner can further perform a weighted fusion of the prediction scores of the second general model and the pre-trained local customized model based on the local validation set to determine the target weighted fusion strategy that yields the highest prediction metric. Then, the second general model, the local customized model, and the target fusion strategy are sent to the model provider for them to provide fused prediction services to the target partner during the inference phase. Based on this, as... Figure 4 As shown, after receiving the second general model, the local customized model, and the target fusion strategy, the model provider can deploy the second general model and the local customized model locally for use in the subsequent inference stage.

[0118] Therefore, in situations where the target partner requires the model provider to offer fusion prediction services, such as... Figure 4 As shown, the target partner can initiate a prediction request to the model provider and simultaneously send the task data required for fusion prediction. Furthermore, as... Figure 4As shown, when the model collaborator receives a prediction request from the target collaborator, it can obtain the task data synchronously sent by the target collaborator. Then, based on the pre-deployed second general model and the target collaborator's local customized model, it performs inference on the task data and obtains corresponding prediction scores. Further, based on the target fusion strategy received from the target collaborator, the model provider can perform weighted fusion of the prediction scores output by the two models to obtain a corresponding fused prediction score. This fused prediction score is then sent to the target collaborator for task decision-making.

[0119] It should be noted that, Figure 4 This paper only illustrates the basic implementation principle and corresponding interaction process of the technical solution of this application. For the specific implementation methods involved in each part, please refer to the description of the corresponding part in the above-mentioned method embodiments, which will not be repeated here.

[0120] It should be further clarified that the first general model sent by the model provider to the target partner, and the second general model, locally customized model, and target fusion strategy sent by the target partner to the model provider method, refer to the model files and related configurations that can be deployed on the other party, excluding the original data on this side. Other necessary content to be transmitted can be determined based on the service requirements between the two parties and is not limited here.

[0121] In summary, in the technical solution provided in this application, the model provider trains a general model based on a local cross-task domain training set. This enables the general model to possess general knowledge across multiple tasks. Furthermore, during training, the model provider introduces task domain identifiers as explicit classification features into the node splitting process of the gradient boosting decision tree, giving the trained general model inherent task awareness and path decision-making capabilities. After receiving the general model generated by the model provider, the target collaborator does not need to perform complex model retraining. It can adapt the general model to the local target task domain based on the local validation set, resulting in extremely low computational cost and processing difficulty. Moreover, there is no need for raw data interaction between the target collaborator and the model provider, which significantly improves the generalization performance of the cross-domain model while ensuring data privacy. Furthermore, by weightedly fusing the prediction scores of the fine-tuned general model and the local customized model, the target collaborator can effectively integrate cross-domain common knowledge with local specific cognition. After sending the fine-tuned general model, the local customized model, and the target fusion strategy between them to the model provider, the accuracy of the fusion prediction service provided by the model provider to the target collaborator during the inference phase can be greatly improved.

[0122] Therefore, the technical solution provided by the embodiments of this application not only ensures data privacy and processing efficiency, but also significantly improves the model generalization ability and prediction accuracy in cross-domain collaboration scenarios, providing a practical and feasible technical path for secure multi-party collaboration.

[0123] It is understood that the execution entity for each step in the above method can be the same device, or the method can be executed by different devices. Furthermore, some processes described in the above embodiments and figures include multiple operations appearing in a specific order; however, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The operation numbers, such as S102, S104, etc., are merely used to distinguish different operations, and the numbers themselves do not limit the execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0124] It should be noted that the terms "first," "second," etc., used in this document are used to distinguish different information, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types. The above embodiments are merely examples, and modifications can be made to the above embodiments in actual implementation. Those skilled in the art will understand that all modifications of the above embodiments without creative effort fall within the protection scope of the embodiments of this application, and will not be described in detail here. All the above optional technical solutions can be referenced or combined with each other to form optional embodiments of this application, and will not be described in detail here.

[0125] Based on the same inventive concept, this application also provides a tree-based cross-domain fusion prediction device, which is applied to a target partner.

[0126] Figure 5a A schematic diagram of the structure of the tree-based cross-domain fusion prediction device 500a is shown, as follows: Figure 5a As shown, the tree-model-based cross-domain fusion prediction device 500a may include a receiving module 501a, a processing module 502a, a fusion module 503a, and an output module 504a, wherein: The receiving module 501a receives a first general model sent by the model provider. The first general model is a gradient boosting decision tree model trained on a multi-task domain training set, wherein at least one decision tree uses the task domain identifier as an explicit classification feature and guides the formation of multiple task domain sub-paths. The processing module 502a uses a validation set of the target task domain to which the target partner belongs to perform lightweight fine-tuning on the first general model to obtain a second general model. The lightweight fine-tuning is used to select the task domain sub-path with the highest prediction index from multiple task domain sub-paths. The fusion module 503a performs weighted fusion of the prediction scores output by the second general model and the local customized model based on the validation set to determine the target weighted fusion strategy. The local customized model is trained on the training set of the target task domain. The output module 504a sends the second general model, the local customized model, and the target weighted fusion strategy to the model provider so that the model provider can provide fusion prediction services to the target partner.

[0127] In an optional embodiment of this application, the processing module 502a uses the validation set of the target task domain to which the target collaborator belongs to perform lightweight fine-tuning on the first general model to obtain a second general model, which is used to: for each decision tree in the first general model, identify multiple candidate task domain sub-paths formed by task domain identifiers as splitting features; use the validation set of the target task domain to which the target collaborator belongs to calculate the prediction index of the multiple candidate task domain sub-paths on the validation set; select the task domain sub-path with the highest prediction index from the multiple candidate task domain sub-paths and mask the leaf node output values ​​of other task domain sub-paths to obtain the second general model.

[0128] In optional embodiments of this application, the prediction metrics include at least one of the area under the receiver operating characteristic curve, the KS statistic, or the log-likelihood loss.

[0129] In an optional embodiment of this application, the weight values ​​of the weighted fusion are fixed weights; or, the weight values ​​of the weighted fusion are variable weights determined based on the optimization of the prediction metrics on the validation set.

[0130] In optional embodiments of this application, the locally customized model includes a scorecard model, a gradient boosting decision tree model, or a random forest model.

[0131] Based on the same inventive concept, this application also provides a tree model training device based on a multi-task domain, which is applied to a model provider.

[0132] Figure 5b A schematic diagram of the structure of the tree model training device 500b based on a multi-task domain is shown, as follows: Figure 5bAs shown, the tree model training device 500b based on a multi-task domain may include an acquisition module 501b, a training module 502b, and an output module 503b, wherein: The acquisition module 501b is used to acquire a multi-task domain training set. Each sample in the multi-task domain training set includes a feature vector, a predicted label, and a corresponding task domain identifier. The training module 502b is used to train a gradient boosting decision tree model based on the multi-task domain training set. During the training process, the task domain identifier participates in the node split gain calculation of each round of the decision tree to obtain a decision tree that forms multiple task domain sub-paths guided by different task domain identifiers. The output module 503b is used to send the trained gradient boosting decision tree model as the first general model to the target partner so that the target partner can perform lightweight fine-tuning of the first general model based on the validation set of the target task domain.

[0133] In an optional embodiment of this application, the training module 502b trains a gradient boosting decision tree model based on a multi-task domain training set, and is used to: encode the category of each task domain identifier in the multi-task domain training set and introduce it as an explicit classification feature into the feature vector to form an enhanced feature vector; construct a joint training set based on the enhanced feature vector and the predicted label; and train the gradient boosting decision tree model using the joint training set.

[0134] In an optional embodiment of this application, the training module 502b trains a gradient boosting decision tree model using a joint training set, which is used to: train the gradient boosting decision tree model on the joint training set using a lightweight gradient boosting machine algorithm or an extreme gradient boosting algorithm.

[0135] Based on the same inventive concept, this application also provides a tree-based cross-domain fusion prediction device, which is applied to the model provider.

[0136] Figure 5c A schematic diagram of the structure of the tree-based cross-domain fusion prediction device 500c is shown, as follows: Figure 5c As shown, the tree-based cross-domain fusion prediction device 500c may include a receiving module 501c, an inference module 502c, a fusion module 503c, and an output module 504c, wherein: The receiving module 501c receives a prediction request sent by the target partner, which includes task data of the target task domain to which the target partner belongs. The inference module 502c performs inference on the task data based on a pre-deployed second general model and the target partner's local customized model to obtain corresponding prediction scores. The local customized model is trained on the training set of the target task domain. The second general model is determined by the target partner after performing lightweight fine-tuning on the first general model provided by the model provider. The first general model is a gradient boosting decision tree model, in which at least one decision tree includes internal nodes with task domain identifiers as splitting features. The fusion module 503c performs weighted fusion on the prediction scores output by the second general model and the local customized model based on a target weighted fusion strategy to generate a fused prediction score. The target weighted fusion strategy is determined by the target partner after performing weighted fusion on the prediction scores output by the second general model and the local customized model based on the validation set of the target task domain. The output module 504c sends the fused prediction score to the target partner so that the target partner can make task decisions for the target task domain based on the fused prediction score.

[0137] In an optional embodiment of this application, before receiving the prediction request sent by the target partner, the receiving module 501c is further configured to: receive the second general model, the local customized model, and the target weighted fusion strategy of the two sent by the target partner; and deploy the second general model and the local customized model to provide fusion prediction services to the target partner.

[0138] It should be noted that, due to Figures 5a-5c The principle by which the device solves the problem is similar to that of the aforementioned method. Therefore, the implementation of the corresponding device can be found in the implementation of the aforementioned method, and repeated details will not be repeated.

[0139] Based on the same inventive concept, this application also provides an electronic device, see [link to relevant documentation]. Figure 6 , Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 may include a processor 601, a memory 602, and a program or instructions stored in the memory 602 and executable on the processor 601. When the program or instructions are executed by the processor 601, they implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0140] It should be noted that the electronic devices in the embodiments of this application include mobile electronic devices and non-mobile electronic devices.

[0141] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the various processes of the above-described method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0142] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0143] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0144] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0145] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0146] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments. In this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Those skilled in the art can understand the specific meaning of the above terms in the embodiments of this application according to the specific circumstances.

[0147] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application is not limited to any single aspect, nor to any single embodiment, nor to any combination and / or substitution of these aspects and / or embodiments. Moreover, each aspect and / or embodiment of this application can be used alone or in combination with one or more other aspects and / or embodiments thereof.

[0148] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of this application.

Claims

1. A cross-domain fusion prediction method based on a tree model, characterized in that, Applied to the target partner, the method includes: The receiving model is a first general model sent by the model provider. The first general model is a gradient boosting decision tree model trained on a multi-task domain training set, wherein at least one decision tree uses the task domain identifier as an explicit classification feature and guides the formation of multiple task domain sub-paths. Using the validation set of the target task domain to which the target partner belongs, the first general model is lightly fine-tuned to obtain the second general model; wherein, the lightly fine-tuning is used to select the task domain sub-path with the highest prediction index from multiple task domain sub-paths; The predicted scores output by the second general model and the local customized model are weighted and fused based on the validation set to determine the target weighted fusion strategy; wherein the local customized model is trained based on the training set of the target task domain; The second general model, the local customized model, and the target weighted fusion strategy are sent to the model provider so that the model provider can provide fusion prediction services to the target partner.

2. The method according to claim 1, characterized in that, Using the validation set of the target task domain to which the target partner belongs, the first general model is lightly tweaked to obtain a second general model, including: For each decision tree in the first general model, identify multiple candidate task domain sub-paths guided by task domain identifiers as splitting features; Using the validation set of the target task domain to which the target partner belongs, calculate the prediction index of the multiple candidate task domain sub-paths on the validation set respectively; The second general model is obtained by selecting the task domain sub-path with the highest prediction index from the multiple candidate task domain sub-paths and masking the leaf node output values ​​of other task domain sub-paths.

3. A cross-domain tree model training method, characterized in that, Applied to the model provider, the method includes: Obtain a multi-task domain training set, wherein each sample in the multi-task domain training set includes a feature vector, a predicted label, and a corresponding task domain identifier; The gradient boosting decision tree model is trained based on the multi-task domain training set. During the training process, the task domain identifiers are involved in the node splitting gain calculation of each round of the decision tree to obtain a decision tree that is guided by different task domain identifiers to form multiple task domain sub-paths. The trained gradient boosting decision tree model is sent as the first general model to the target partner, so that the target partner can perform lightweight fine-tuning of the first general model based on the validation set of the target task domain.

4. The method according to claim 3, characterized in that, Training a gradient boosting decision tree model based on the multi-task domain training set includes: Each task domain identifier in the multi-task domain training set is categorically encoded and introduced into the feature vector as an explicit classification feature to form an enhanced feature vector; A joint training set is constructed based on the enhanced feature vector and the predicted label; The gradient boosting decision tree model is trained using the joint training set.

5. A cross-domain fusion prediction method based on a tree model, characterized in that, Applied to the model provider, the method includes: Receive a prediction request sent by a target partner, the prediction request including task data of the target task domain to which the target partner belongs; Based on the pre-deployed second general model and the target partner's local customized model, inference is performed on the task data to obtain corresponding prediction scores; wherein, the local customized model is trained on the training set of the target task domain; the second general model is determined based on the target partner's lightweight fine-tuning of the first general model provided by the model provider, and the first general model is a gradient boosting decision tree model, wherein at least one decision tree includes internal nodes with task domain identifier as the splitting feature; Based on the target weighted fusion strategy, the prediction scores output by the second general model and the local customized model are weighted and fused to generate a fused prediction score; wherein, the target weighted fusion strategy is determined by the target partner based on the validation set of the target task domain, after weighting and fusing the prediction scores output by the second general model and the local customized model. The fusion prediction score is sent to the target partner so that the target partner can make task decisions for the target task domain based on the fusion prediction score.

6. A cross-domain fusion prediction device based on a tree model, characterized in that, Applied to a target partner, the device includes: The receiving module is used to receive a first general model sent by the model provider. The first general model is a gradient boosting decision tree model trained on a multi-task domain training set, wherein at least one decision tree uses the task domain identifier as an explicit classification feature and guides the formation of multiple task domain sub-paths. The processing module is used to perform lightweight fine-tuning on the first general model using the validation set of the target task domain to which the target partner belongs, to obtain a second general model; wherein, the lightweight fine-tuning is used to select the task domain sub-path with the highest prediction index from multiple task domain sub-paths. The fusion module is used to perform weighted fusion of the prediction scores output by the second general model and the local customized model based on the validation set to determine the target weighted fusion strategy; wherein the local customized model is trained based on the training set of the target task domain; The output module is used to send the second general model, the local customized model, and the target weighted fusion strategy to the model provider, so that the model provider can provide fusion prediction services to the target partner.

7. A tree model training device based on a multi-task domain, characterized in that, Applied to a model provider, the device includes: The acquisition module is used to acquire a multi-task domain training set, wherein each sample in the multi-task domain training set includes a feature vector, a predicted label, and a corresponding task domain identifier. The training module is used to train a gradient boosting decision tree model based on the multi-task domain training set. During the training process, the task domain identifiers are involved in the node splitting gain calculation of each round of the decision tree to obtain a decision tree that is guided by different task domain identifiers to form multiple task domain sub-paths. The output module is used to send the trained gradient boosting decision tree model as the first general model to the target partner, so that the target partner can perform lightweight fine-tuning of the first general model based on the validation set of the target task domain.

8. A cross-domain fusion prediction device based on a tree model, characterized in that, Applied to a model provider, the device includes: A receiving module is used to receive a prediction request sent by a target partner, the prediction request including task data of the target task domain to which the target partner belongs; The inference module is used to infer the task data based on a pre-deployed second general model and a local customized model of the target partner, respectively, to obtain corresponding prediction scores; wherein, the local customized model is trained based on the training set of the target task domain; the second general model is determined based on the first general model provided by the model provider after the target partner performs lightweight fine-tuning, and the first general model is a gradient boosting decision tree model, wherein at least one decision tree includes internal nodes with task domain identifiers as splitting features; The fusion module is used to perform weighted fusion of the prediction scores output by the second general model and the local customized model based on a target weighted fusion strategy to generate a fused prediction score; wherein, the target weighted fusion strategy is determined by the target partner based on the validation set of the target task domain after weighted fusion of the prediction scores output by the second general model and the local customized model. The output module is used to send the fusion prediction score to the target partner so that the target partner can make task decisions for the target task domain based on the fusion prediction score.

9. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein, when the computer program product is executed, it implements the method described in any one of claims 1-5.

10. A computer-readable storage medium storing a computer program, characterized in that, The computer program is configured to implement the method of any one of claims 1-5 when executed by a processor.

Images