Decentralized training methods suitable for completely different training sets

Abstract

Some embodiments are directed to training a model, e.g., a medical model. The training uses a plurality of model updates received from a plurality of client systems. At least some of the plurality of clients train on a training set that indicates values of different features. The model updates are aggregated in an aggregated model for which feature weights are obtained. The feature weights provide information about the relative importance of the plurality of features to the output of the aggregated model.

Description

Technical Field

[0001] The currently disclosed topics relate to computer-implemented server methods for training models, computer-implemented client methods for training models, server systems for training models, client systems for training models, and computer-readable media. Background Technology

[0002] Predicting the likelihood of disease is a useful application of predictive models. For example, cardiovascular disease (CVD) is a leading cause of death worldwide and a major public health problem. Over the past decade, several risk prediction models for CVD have been developed for different populations. For instance, a predictive model can take various features as input and output the likelihood (e.g., probability) that a person is affected by or will be affected by a predicted disease (e.g., CVD) corresponding to the input feature values. Such predictions can be used for various purposes, such as lifestyle-targeted interventions and enhanced surveillance in hospital settings.

[0003] Conventionally, such models are developed by collecting large datasets and training the model on these datasets. An example of a predictive model is given in US Patent 6,869,802, which is incorporated herein by reference. In the known model, information indicating the level of coronary artery disease in a group of 877 individuals was collected, with the disease level ranging from no disease to severe. Furthermore, values ​​for a range of features were collected, including age, various types of cholesterol levels, etc. Stepwise discriminant analysis was performed on the dataset to obtain a model that predicts the level of coronary artery disease based on the feature values. As a result, a predictive model was obtained; in this case, a predictive model for coronary artery disease.

[0004] One problem with this traditional approach is the need for a complete dataset at a central location. Having a central dataset makes it easier to ensure data consistency and high quality. Any algorithm that derives a model from the data can then run locally.

[0005] Unfortunately, centralized approaches are becoming increasingly difficult, especially with the continued growth in dataset size. Developing predictive models to determine the risk of medical conditions, for example, requires more data due to increased model sensitivity or the increased number of features included. Privacy concerns, for instance, make it increasingly difficult to collect the necessary data at a central location. This is often an obstacle, especially if the data must come from different sources (e.g., different hospitals).

[0006] Various technical solutions have been proposed to address this problem. For example, the paper "Communication-Efficient Learning of Deep Networks from Decentralized Data" (incorporated hereby by reference) proposes a decentralized training method called "Federated Learning." In Federated Learning, mobile phones train neural networks based on locally available training data. A shared model is obtained by aggregating the locally computed model updates.

[0007] Unfortunately, federated learning does not solve all the problems associated with the loss of a central setting used to train the model. While the training algorithm runs locally in federated learning, a high degree of centralized control over the process is still maintained. For example, the locally running software (e.g., the "application") can ensure such control to, for instance, ensure data consistency. Such a high level of control is not always feasible. Summary of the Invention

[0008] Computationally efficient and privacy-conscious solutions to large-scale machine learning problems are becoming increasingly important, especially in healthcare, where acquiring and removing data from hospitals presents challenges. Federated learning enables hospitals to collaboratively learn shared predictive models without removing data from the hospital premises. However, federated learning still assumes that the data used by participating sites is highly consistent. Furthermore, it assumes that the models used by participating sites are identical. In reality, this is not the case. For example, the training sets available at different sites may be completely different; for instance, different features may be used for predictions at different sites. Improved distributed training methods would be advantageous.

[0009] In this embodiment, the model is improved by aggregating model updates from multiple clients. The aggregating model is configured to receive multiple feature values ​​representing multiple features. The features for which the aggregating model allows its values ​​are referred to as the principal feature set. Not all clients need to share the principal feature set. Not all clients need the same feature set. Feature weights are obtained for the aggregating model, representing the relative importance of multiple features to the output of the aggregating model. Feature weights represent information that is not available locally on the client and cannot actually be computed locally because individual clients may lack training data to properly evaluate the aggregating model. The same applies to servers (e.g., aggregators) that aggregate model updates. Nevertheless, feature weights are still important because they essentially tell us which features are worth starting to capture. Therefore, the server can share information based on weights to improve clients. For example, the server can inform a client which feature (that the client is not currently using) should be started to improve its local predictions. The server can also send a list of all aggregated feature weights or the most important feature weights, regardless of whether the receiving client uses the corresponding feature.

[0010] Advantageously, feature weights can be obtained in a distributed manner. For example, the aggregated model obtained at the server can be distributed to clients. Clients can evaluate the aggregated model using local training samples and thus derive client-side feature weights. For instance, clients can apply the aggregated model to local training samples and determine which features of the tested training samples are important for the outcome of the aggregated model. The server can then aggregate the client-side feature weights into global feature weights. The latter effectively illustrates the importance of various features.

[0011] The embodiments can be applied to medical models configured to receive medical feature values ​​as input and / or predict medical conditions. The embodiments can also be applied to other types of models, such as models that predict the future technical state of a technical system (e.g., an engine) based on current sensor values, system history, etc.

[0012] Both the server system and the client system can be implemented as electronic devices, such as computers. Embodiments of the method can be implemented on a computer as a computer-implemented method, or in dedicated hardware, or a combination of both. Executable code for embodiments of the method can be stored on a computer program product. Examples of computer program products include storage devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product includes non-transient program code stored on a computer-readable medium for executing embodiments of the method when the program product is run on a computer.

[0013] One aspect involves a training system comprising a server system and multiple client systems. Another aspect involves a training method comprising server methods and client methods; for example, the training method can be distributed across the server system and multiple client systems for operation.

[0014] In an embodiment, the computer program includes computer program code that, when run on a computer, is adapted to perform all or part of the steps of an embodiment of the method. Preferably, the computer program is implemented on a computer-readable medium. Attached Figure Description

[0015] Further details, aspects, and embodiments will be described with reference to the accompanying drawings and by way of example only. Elements in the drawings are shown for simplicity and clarity and are not necessarily drawn to scale. In the drawings, elements corresponding to those already described may have the same reference numerals. In the drawings,

[0016] Figure 1a An example of an embodiment of the training system is illustrated schematically.

[0017] Figure 1b An example of an embodiment of the training system is illustrated schematically.

[0018] Figure 1c An example of an embodiment of the training system is illustrated schematically.

[0019] Figure 2a An example of an embodiment of a server training system is illustrated schematically.

[0020] Figure 2b An example of an embodiment of a server training system is illustrated schematically.

[0021] Figure 3a An example of an embodiment of the client-side training system is illustrated schematically.

[0022] Figure 3b An example of an embodiment of the feature set is illustrated schematically.

[0023] Figure 4a An example of an embodiment of the training system is illustrated schematically.

[0024] Figure 4b An example of an embodiment of the training system is illustrated schematically.

[0025] Figure 5 An example of an embodiment of the server training method is illustrated schematically.

[0026] Figure 6 An example of an embodiment of the client-side training method is illustrated schematically.

[0027] Figure 7a A computer-readable medium having a writable portion including a computer program, according to an embodiment, is illustrated schematically.

[0028] Figure 7b A representation of a processor system according to an embodiment is shown schematically.

[0029] Figures 1a-4b List of reference numerals in figures 7a-7b:

[0030] The following list of reference numerals and abbreviations is provided to facilitate the interpretation of the drawings and should not be construed as limiting the claims.

[0031] 100-103 Client System

[0032] 150, 250 processor systems

[0033] 160, 260 storage devices

[0034] 170, 270 communication interfaces

[0035] 200-202 Server System

[0036] 211-212 Server System

[0037] 213 Model Communication

[0038] 214 Feature Communication

[0039] 210 Basic Training Set

[0040] Training Unit 231

[0041] 232 Evaluation Unit

[0042] 220 Model Parameters

[0043] 222 Model Aggregator

[0044] 240 Feature Weight Determiner

[0045] 241 Feature Weights

[0046] 242 Feature Weight Aggregator

[0047] 310 Client Training Set

[0048] 311 Client System

[0049] 320 Model Parameters

[0050] 322 Model Update Unit

[0051] 331 training units

[0052] 332 Evaluation Unit

[0053] 340 Feature Weight Determiner

[0054] 341 Feature Weights

[0055] Feature set 351-353

[0056] Features 361-364

[0057] 400 server

[0058] 411 Aggregator Package

[0059] 412 Aggregation Model

[0060] 413 Model Interpreter

[0061] 414 Feature Differentiator

[0062] 415 Feature Transfer

[0063] Clients 421-423

[0064] Participating sites 430 and 440

[0065] 431, 441 Client Model

[0066] 432, 442 client predictions

[0067] 433, 443 Client Interpreter

[0068] Feature weights of 434 and 444

[0069] 450 sites

[0070] 451 Aggregation Model

[0071] 452 Prediction

[0072] 453 Interpreter

[0073] 454 Feature Weights

[0074] 1000, 1001 Computer-readable media

[0075] 1010 writable portion

[0076] 1020 Computer Program

[0077] 1110 (one or more) integrated circuits

[0078] 1120 Processing Unit

[0079] 1122 Memory

[0080] 1124 Application-Specific Integrated Circuit

[0081] 1126 Communication Components

[0082] 1130 Interconnection

[0083] 1140 Processor System Detailed Implementation

[0084] While the subject matter disclosed herein allows for many different forms of embodiments, one or more specific embodiments are shown in the accompanying drawings and will be described in detail herein. It should be understood that this disclosure is intended to be an example of the principles of the subject matter disclosed herein and is not intended to limit it to the specific embodiments shown and described.

[0085] In the following description, for ease of understanding, the elements of the embodiments are described in operation. However, it will be apparent that the various elements are arranged to perform the functions described as being performed by them. Furthermore, the subject matter disclosed herein is not limited to the embodiments, but also includes all other combinations of features described herein or recited in mutually different dependent claims.

[0086] Figure 1a An example of an embodiment of the training system is illustrated schematically. Figure 1a The diagram illustrates server system 200 and client system 100. Although only one client system is shown, in a typical embodiment, there is one server system 200 and multiple client systems 100. It is possible to have multiple server systems 200.

[0087] For example, client system 100 can be used to locally train a model on a local client training set and send model updates to server system 200. Server system 200 can be configured to aggregate model updates from multiple clients into an aggregate model. The features used by the multiple clients do not need to be consistent; for example, they do not need to be the same on multiple clients. Completely different training sets (e.g., training sets that do not use the same feature set) are a problem with existing methods. Server system 200 and client system 100 can collaborate to determine feature weights that indicate which features are important for prediction. Client system 100 can use this information to further improve its model.

[0088] Client system 100 may include processor system 150, storage device 160, and communication interface 170. Server system 200 may include processor system 250, storage device 260, and communication interface 270.

[0089] Storage devices 160 and 260 may include local storage devices, such as local hard disk drives or electronic storage devices. Storage devices 160 and 260 may also include non-local storage devices, such as cloud storage devices. In the latter case, storage devices 160 and 260 may include storage interfaces to non-local storage devices. Systems 100 and / or 200 may communicate internally with each other and with other systems, external storage devices, input devices, output devices, and / or one or more sensors via a computer network. The computer network may be the Internet, an intranet, a local area network (LAN), a wireless LAN, etc. The system includes a connection interface arranged to enable intra-system or inter-system communication as needed. For example, the connection interface may include connectors, such as wired connectors (e.g., Ethernet connectors, optical connectors, etc.) or wireless connectors (e.g., antennas, such as Wi-Fi, 4G, or 5G antennas).

[0090] In systems 100 and 200, communication interfaces 170 and 270 can be used to send or receive digital data. For example, client system 100 can send model updates, receive aggregated models, and send or receive feature weights and / or other feature information. For example, server system 200 can receive model updates, send aggregated models, and send or receive feature weights and / or other feature information.

[0091] The operation of systems 100 and 200 can be implemented in a processor system (e.g., one or more processor circuits, such as a microprocessor, examples of which are shown herein). The processor system may include a GPU and / or a CPU. Both systems 100 and 200 may include multiple processors, which may be distributed in different locations. For example, systems 100 and 200 may utilize cloud computing.

[0092] Other accompanying figures illustrate functional units that can be implemented as functional units in a processor system. For example, Figures 2a-4bThese can be used as blueprints for possible functional organization forms of a processor system. The processor circuitry(s) are not shown as separate from the units in these figures. For example, the functional units shown in the figures can be implemented, wholly or partially, using computer instructions stored at system 100 and / or 200 (e.g., stored in the electronic memory of system 100 and / or 200), and can be run by the microprocessors of system 100 and / or 200. In hybrid embodiments, the functional units are implemented partly in hardware (e.g., implemented as coprocessors, such as neural network coprocessors, etc.) and partly in software stored and running on system 100 and / or 200. One or both of systems 100 and 200 can be implemented as devices. For example, in an embodiment, the client system is implemented as a client device, while the server system is implemented as a distributed computing system. The server system can also be a device.

[0093] Cardiovascular disease (CVD) will be considered as an inspiring example in this paper. CVD is a leading cause of death worldwide and a major public health problem. Several risk prediction models for cardiovascular disease have been developed for different populations over the past decade. However, the examples can also be applied to other medical applications. For example, the model can be a medical model, such as one that receives medical data as input and / or generates medical data as output. The model can be predictive, for example, to predict medical conditions (e.g., CVD).

[0094] For example, federated learning can be used to train a cardiovascular disease risk prediction model across different sites. This example model uses logistic regression to train the model. The example model receives values ​​from various features that may be related to CVD.

[0095] Generally speaking, assuming a model has n features and p data samples, the probability of cardiovascular disease can be calculated by considering each feature. The obtained predictor vector ,and These are regression coefficients, which indicate the relevance of predictors or their contribution to the outcome category. Given a vector of predictors... The probability of performing CVD can be modeled as:

[0096]

[0097] Parameters can be obtained by applying multiple training iterations to the training dataset. For example, gradient descent can be used to oriented towards parameters. Convergence. Many other types of models and training are possible, some of which will be discussed further in this paper.

[0098] In an embodiment, a server system, sometimes referred to as a coordinator or aggregator, builds a base model that is configured to receive the values ​​of a list of many possible features of a CVD model as input. The base model is built upon this set of features. If the coordinator has a base training set, initial training can be performed on that dataset. The base model is then sent to multiple client systems. In this embodiment, the clients train on the same base model. Clients train the base model on locally available data. Clients do not need to use the same features. If a client does not have data for a particular feature, that feature will not be used at that client. Model updates are sent from the clients to the server system. Model updates may include information about how the base model should be modified to improve its predictions on local data. For example, a model update may include an updated model; a model update may include parameter updates, information indicating how parameters should be changed (e.g., increased, decreased, or replaced); a model update may include training information (e.g., gradients).

[0099] The server system can use model updates to compute the aggregate model based on those updates. Additional training on local data (potentially multiple rounds) improves the quality of the aggregate model.

[0100] Interestingly, weights can be calculated for features. For example, model updates can also include weights for each feature. The weights of missing features can be set to zero, etc., since these features were not captured. Feature weights received at the server system can also be aggregated (e.g., averaged).

[0101] For example, techniques like federated averaging can be used for aggregation. In this embodiment, missing feature weights are not considered for aggregation; for example, they are not included in the average. For instance, C1, C2, and C3 are considered as three separate clients; f1 and f2 are considered as features; and A, B, C, and D are considered as coefficients. For simplicity, it is assumed that each feature is weighted with a single coefficient, for example, as in logistic or linear multiple regression. The model update received from the clients can then be represented as:

[0102] C1: A*f1 (f2 feature missing)

[0103] C2: B*f2 (f1 feature missing)

[0104] C3: C*f1+D*f2

[0105] In other words, client C1 sends update parameters for feature f1, but not for feature f2, because the latter is not used by C1. On the other hand, C3 sends update parameters for both features. The aggregate model can be represented as (A+C)*f1 / 2 + (B+D)*f2 / 2. To calculate the set parameters of the features, only those model updates corresponding to the clients using those features are considered.

[0106] In this example, the client sends the updated parameter value, but the client can also alternatively send the increment compared to the previous parameter value. For example, client C1 could send (A-A'), where A' represents the previous common value of the parameter for f1. As will be further expanded upon in this paper, this aggregation example can be varied in many ways, such as changing to more parameters, features, different types of averaging, etc.

[0107] In this way, information that cannot be discovered independently is revealed—both the base training set and the client dataset may be insufficient (e.g., large enough or varied enough) to reveal the true importance of certain features, such as feature weights. However, once this information is gathered, clients are able to independently improve their models, for example, automatically or manually, depending on the specific context. For instance, the following is a sample list of coefficients received after training for a CVD use case at a specific client. This data is obtained from a simulation of the system; while it does not represent the true weights of CVD diseases, it represents an implementation. These values ​​were obtained using LIME, but any other interpretability tool could be used. In the table below, various sites (e.g., client systems) report to the server system (e.g., an aggregator). Note that some clients do not use a certain feature, indicated by a weight of "0". For example, clients 1 and 4 do not include the feature 'smoking' in their client training sets; for example, this data may not have been captured at the corresponding site.

[0108]

[0109] The server system calculates the aggregate weight based on the feature weights reported by the client system. In this example, the aggregate weight is calculated by averaging the weights of each feature. Sites that do not consider a particular feature are excluded, so the aggregate weight is calculated only from sites that use the corresponding feature. For example, the aggregate weight for smoking is the sum of the weights of the three reported features divided by three, since three sites consider this feature. This can be viewed as a weighted average, where sites that do not use the particular feature are assigned a weight of 0.

[0110] Features with aggregation weights above a threshold are considered important. For example, in this case, the threshold could be set to 0.1, making all features except body mass index (BMI) and retinopathy considered important. Specifically, the smoking feature has a high weight after aggregation (0.167), indicating that this feature is important for model training and inference. Communicating this information with Site 1 and Site 4 will help capture data with missing features in the future. On the other hand, the BMI feature has an aggregation weight below the threshold of 0.046. Although Site 3 did not record this feature, it is not necessary to convey to Site 3 that it could improve its model by incorporating this particular feature into their system.

[0111] CVD is an example of a disease that can be predicted based on eigenvalues. Predictive models can be learned locally, and these models can discover which features are important through distributed analysis. Predicting CVD is just one example of a model that can potentially undergo distributed feature analysis. For example, other medical predictive models can be trained in this way. For example, server and client systems configured as described herein can also be applied to other data domains. For example, in this embodiment, engine emissions can be estimated based on various eigenvalues, including, for example, speed, vehicle age, vehicle model, number of cylinders, cylinder volume, cylinder pressure, etc. Participants in model training may disagree on the features that should be included in the model, but by using this embodiment, these features can be answered in a distributed manner. For example, the base model can be refined through local training on sensor data obtained locally in the vehicle, without having to upload the data. In this embodiment, one or more eigenvalues ​​are obtained from sensors and input to the model. For example, blood pressure, blood glucose levels, cylinder pressure, speed, etc., can be measured by a blood pressure sensor, a blood glucose level sensor, a cylinder pressure sensor, and a speed sensor, respectively. Sensors can be incorporated into the client system, and / or the client system can be provided with an interface for receiving sensor signals.

[0112] Figure 1b An example of an embodiment of the training system is illustrated schematically. Figure 1b The diagram illustrates server system 200 and multiple client systems; client systems 101, 102, and 103 are shown. The server and client systems exchange various messages (e.g., digital messages) via a computer network, for example.

[0113] Figure 1b Model communication 213 related to the model and feature communication 214 related to the weights are shown.

[0114] For example, model communication 213 may include distributing a trained base model from a server system to multiple client devices, receiving multiple model updates from multiple client devices at server system 200, and distributing an aggregated model to multiple client devices. Some of these operations are optional. For example, if some training schemes do not require a base model, then base model distribution is not necessary. For example, if only a single round of training is performed, or only a single round of training is performed for this set of client systems, then distributing the aggregated model is not necessary.

[0115] For example, feature communication 214 may include receiving multiple client feature weights of the aggregated model from multiple clients at server system 200 and sending signals indicating specific features to the corresponding client devices. Receiving feature weights from client systems can be avoided, making this communication optional; for example, if the basic training set is sufficiently rich, the feature weights can be determined at the server system. For example, the server system may maintain a reserved portion of the training dataset to evaluate the feature weights. This reserved set is not used to train the model and is not shared with the client systems.

[0116] Figure 1c An example of an embodiment of the training system is illustrated schematically. Figure 1c The training system shown is about Figure 1c Variations of the described embodiments. Figure 1c In this system, system 200 is distributed across feature subsystem 201 and model subsystem 202. For example, feature subsystem 201 can be configured for tasks related to feature weights, such as receiving feature weights from multiple client systems, aggregating these feature weights, and conveying important features. For example, model subsystem 202 can be configured for tasks related to models, such as training and distributing a base model, aggregating model updates, etc.

[0117] Subsystems 201 and 202 do not need to communicate with each other. In this embodiment, these subsystems can operate independently of each other. In this embodiment, there may be other subsystems to which both subsystems 201 and 202 report.

[0118] Figure 2a An example embodiment of server training system 211 is illustrated schematically. For example, training system 211 can be configured for a distributed training scheme, e.g., distributed across multiple client systems. For example, server system 211 and client systems can be implemented as systems 200 and 100, respectively. For example, server system 211 can be implemented as systems 201 and 202. For example, client systems can be configured as in the embodiments, e.g., regarding... Figure 3aAs discussed above. The training system 211 can be configured to obtain feature weights for features used by one or more client systems, but not by all client systems. The training system 211 can communicate to client systems that do not use a particular feature that incorporating that feature can improve the accuracy of their models.

[0119] For example, the trained model could be a medical model, such as one configured to receive medical feature values ​​as input and / or predict medical conditions. This is not mandatory; for example, the model may be related to a different domain. For instance, the model might be configured to receive sensor values ​​representing technical characteristics of a physical system (e.g., a device, such as an engine, etc.).

[0120] The client systems associated with the server system 200 may have local models. These client models may be similar, but do not need to be exactly the same. For example, their corresponding feature sets may overlap but are not exactly the same. Preferably, the underlying model configuration is the same, but this is not strictly required.

[0121] For example, a client system could be associated with a hospital. The hospital could train its model on its available data using features relevant to its clinical environment or features more readily available to it. While the hospital may have access to additional features, there could be good reasons why it doesn't use them in its model. For example, the data might be available but needs to be digitized before it can be accessed. Additional features might be available from the data, but might require a domain expert, such as a physician, to evaluate the available data. For example, a physician might need to evaluate medical images to make the additional features digitally accessible. The hospital might be willing to invest in managing the values ​​corresponding to specific features, but might first need some assurance that the additional features will be helpful.

[0122] Federated learning and other decentralized training methods make it easier to train models using data available only locally. However, these known methods still assume that the data is consistent, i.e., that all the multiple clients use the same features. In practice, it has been found that this is not always the case. For example, hospitals might be willing to collaborate and train advanced models by contributing model updates to an aggregate model, but in practice, this is not directly possible due to differences in the feature sets used.

[0123] In an embodiment, server system 211 is configured to train a base model on a base training set. The base model can serve as a starting point for local training by clients. The base model is distributed across multiple client devices. For example, in an embodiment, server system 211 includes a base training set 210, such as a base training set storage format. Server system 211 may also include a training unit 231. Training unit 231 is configured to train base model parameters on the base training set. Typically, training unit 231 iteratively applies training epochs suitable for the selected model. For example, training unit 231 may iteratively apply backpropagation to examples in the base training set. The trained base model can be the initial values ​​for model parameters 220. Model parameters 220 can be distributed across multiple clients as a starting point for their distributed training. For example, a client may send a model update that is an update to the base model.

[0124] Not all client systems use the same feature set. One way to accommodate this is to arrange the base model with many inputs. For example, the base model can be configured to allow feature values ​​from any feature in the master feature set. A master set is chosen such that all features commonly used by multiple clients are included in the master set. Features in the master set can be identified using feature IDs. For example, feature IDs can be taken from standardized coding schemes for medical data, such as LONIC or HL7.

[0125] A base model is trained on a basic training set. Preferably, the basic training set contains examples of all features from the main training set, but this is not mandatory. In any case, some clients will not have data containing all features from the main feature set. There are various ways to use the model without requiring feature values ​​for all features that may appear in the input; some of these will be explained further in this paper. These techniques can be used by client or server systems that need to apply the model to data containing feature values ​​for one or more features that do not have the model (e.g., the base model).

[0126] For example, in one embodiment, the size of the primary feature set is larger than the features used by at least one client system; for example, the size of the primary feature set is at least 1.5 times the size of the client feature set. For example, in one embodiment, the primary feature set may have, for example, 30 features, while the client device may use only 20 features. Larger feature sets are also possible. In one embodiment, the primary feature set is much larger than the feature sets of some clients.

[0127] The advantage of using a base model as a starting point is that customer-developed models are more similar because they start from the same point. Another advantage of using a base model is that model updates can be sent as parameter increments, rather than having to send the full set of parameters. However, using a base model is not necessary. For example, if the model is linear or nearly linear, then the model itself can be meaningfully averaged without requiring the client to start from a base model. If no base model is trained, then a trainer 231 is also unnecessary. System 211 may include an evaluation unit 232, allowing server 211 to be used to evaluate the model; for example, evaluation unit 232 can be used by trainer 231. Server 211 itself can also be used.

[0128] In an embodiment, server system 211 may be configured to receive multiple model updates from multiple client devices and aggregate the multiple model updates to obtain an aggregated model. For example, server system 211 may include model aggregator 222, which is configured to receive model updates and aggregate them. Model updates represent model parameters improved by the client devices during training iterations run on the corresponding client training sets. For example, a client device may receive a model from server system 211, such as a base model, and continue to train it further using locally available training data, such as using the same type of training algorithm used by training unit 231. A portion of the training samples used by one or more client systems will miss some features that could be input into the model, such as features in the main feature set.

[0129] In this embodiment, the aggregation model and / or the base model are arranged to receive feature values ​​from the main feature set as input. Training samples at the client systems indicate the values ​​of features in the main feature set. They may contain more information not used by the base model or the aggregation model. At least one client system does not use all features from the main feature set. For example, at least two client systems use different subsets of the main feature set.

[0130] The client system may be trained on client-specific training data only available to that particular client. However, the client training set may be incomplete, as it contains feature values ​​for all features in the main feature set. This is the case for at least some of the multiple client training sets. For example, there may be at least two client training sets indicating feature values ​​for different features.

[0131] Server 211, such as aggregator 222, can be configured to receive model updates and aggregate them. For example, aggregating model updates can be done by averaging them, possibly by weighted averaging, for example, weighted relative to the size of the corresponding client training set. For example, aggregation can use known aggregation algorithms, such as those described in the background art.

[0132] Once the model updates have been aggregated into the model, the model parameters 220 can be updated. The model, represented by the model parameters, is now trained on more data than is available in the base training dataset 210. If needed, the aggregated model can be distributed to multiple client devices. For example, the server system and client systems can perform multiple iterations of training the model locally, sending model updates from multiple client devices to the server system, aggregating multiple model updates to obtain a further aggregated model, and distributing the further aggregated model.

[0133] Model updates may include the client model parameters themselves. Model updates may include differences between the client model parameters and previous iterations of the model (e.g., the base model). Aggregation may include averaging model updates. In embodiments, aggregation is not performed by averaging parameters, but rather by merging selected client models into the overall model. For example, in embodiments, aggregation includes selecting two or more of a plurality of model updates and configuring the overall model from the selected model updates. The ensemble model may include a combination portion to combine the model outputs of the models in the ensemble. The overall model may use a boosting algorithm to combine the model outputs, such as AdaBoosting.

[0134] In this embodiment, server 211 is configured to obtain feature weights of the features used by the aggregation model. Feature weights represent the relative importance of multiple features output by the aggregation model. There are at least two methods to obtain feature weights, and they can also be used in combination.

[0135] For example, feature weights can be determined locally on server system 211. System 211 may include a feature weight determiner 240. Feature weight determiner 240 can apply an algorithm, such as an interpretability algorithm, to all or part of the basic training set to determine the feature weights. This has advantages such as the ability to compute feature weights locally without network overhead. Feature weights can be readily available once a new aggregation model becomes available. However, such an approach only works well when the basic training set is relatively rich; in particular, features missing from the basic training set may not be well evaluated.

[0136] Another method for obtaining feature weights is to obtain them from multiple clients. For example, in an embodiment, obtaining feature weights for an aggregated model includes receiving multiple client feature weights for the aggregated model determined by multiple clients and aggregating the client feature weights. For example, server system 211 may aggregate model updates, such as new values ​​for model parameter 220, within the aggregated model. The aggregated model is then distributed to client systems, such as multiple client systems.

[0137] Locally, at multiple client systems, the aggregated model is installed as a new model. Each client system can evaluate the new model on locally available training data. Specifically, the client system can determine the feature weights of the aggregated model. The client system can do this using the same algorithm as server system 211, for example, as feature weight determiner 240. For example, a weight feature algorithm, such as an interpretability algorithm, can be applied to all or part of the client training set. The locally determined weight features are sent from the client system to the server system. At the server system, they can be aggregated, for example, using an average, such as a weighted average. For example, system 211 may include feature weight aggregator 242.

[0138] For example, weights can be proportional to the number of training samples used to evaluate feature weights. For example, they can be averaged only on those client systems that use a particular feature. For example, if only 10 out of 15 client devices use a particular feature, the weights can be averaged over the 10 features, excluding the weights of 0 for the 5 client systems that do not use the feature.

[0139] The average used to aggregate feature weights can be an arithmetic mean. Other types of averages can also be used. For example, instead of an arithmetic mean, a power mean, such as the root mean square (RMS), also known as a quadratic mean, can be used. A higher power can be used instead of a power of 2. One advantage of using a power mean is that it emphasizes individual high values; this can be an advantage if the feature is not important to many client systems that use it. The consequence can be that feature weights important at one client system are diluted too much by small feature weights found at other client devices. This latter scenario can occur, for example, if the feature is used on a small number of client systems and / or a small number of training samples on those client systems.

[0140] The feature weights obtained by server 2111, such as locally determined and / or aggregated from or together with client feature weights, can be used to select which features are important for the model output, for example, for the variables being modeled, such as disease prediction, sensor prediction, etc. For example, server 211 can send the aggregated model's feature weights to the client system. At the client system, this information can be used to improve the local model, for example, by changing the collected data and thus by adding one or more features to the client training data. This does not necessarily mean that existing client training data needs to be expanded with new features; instead, one can use new features on new training samples added to the client training set.

[0141] Feature weights represent the relative importance of multiple features in the aggregated model output. Therefore, adding features with high weights (e.g., above a threshold) is expected to improve predictions. Conversely, one could stop adding record feature values ​​for features that have little impact on the model's predictive power.

[0142] In an embodiment, server 211 can select client devices that do not use a particular feature but that feature is important, for example, those with a weight higher than a threshold. For example, server 211 can determine which features are not used by client devices, as this can be indicated in the client's communications. For example, the feature weight can be 0, or it can have a value indicating that it is not used.

[0143] Server 211 is configured to select one or more important features, such as features with feature weights above a threshold. This selection can also be relative; for example, the top k features, such as the top 10 features, can be selected. For instance, the top k%, or the top 10% of features, can be selected as a percentage k. In this embodiment, the client system can therefore receive a message indicating that the client is not using a specific feature, but it is advised to do so because this would likely improve the predictions obtainable by the client system.

[0144] For example, suppose a hospital does not record the smoking feature when predicting CVD. Upon aggregation, it might be found that not recording this feature weakens the predictive capabilities the hospital can implement. Information that smoking is an important feature is unavailable at the hospital and not easily obtained locally because the feature is not recorded there and therefore will not appear in the statistical analysis of its data. At server 211, this knowledge becomes available, for example, by determining feature weights and / or aggregating feature weights from other client systems; for example, information that smoking is an important factor to consider when predicting CVD. Therefore, the server system can send a message to this specific client device indicating that smoking is an important feature. Consequently, the corresponding hospital might change its policy and begin recording this feature. It could even be a case where the information is available in one of the hospital's systems, for example, a database with record forms, but this information is not included in the hospital's modeling. In such cases, by providing information to the model, an improvement in predictive capability can be achieved relatively easily. Therefore, this example makes important information that is not available locally available available.

[0145] In this embodiment, the feature weights of the aggregated model are obtained by combining client-side feature weights, for example, using feature weights computed locally on the client-side training set. The server can add its own set of feature weights by computed feature weights from the base training set. Using the base training set is unnecessary for determining the feature weights, as only client-side feature weights are available.

[0146] For example, in one embodiment, the aggregated model is distributed across client systems. All or some client systems compute the feature weights of the aggregated model and send them to server 211. Server 211 can determine the aggregated feature weights from the multiple client feature weights. The aggregated feature weights can also be referred to as global feature weights. For example, the client feature weights can be averaged. In one embodiment, the feature weights are aggregated by considering only the feature weights of client systems that use the feature. The advantage of the latter is that feature weights used only by a few client systems are diluted too much by the zero feature weights of client systems that do not use them. Before recommending feature weights is important, the server can verify whether a sufficient number of training samples were used to determine the feature weights. For example, client systems can report not only the feature weights but also how many training samples indicate the value of that particular feature. This number can also be used, or alternatively, for a weighted average.

[0147] The relative importance of a feature (e.g., represented numerically as feature weights) can be calculated by applying a model (e.g., an aggregated model) to training samples and determining the feature weights of the samples (e.g., the relative importance of a feature to that particular training sample). Feature weights can be calculated by aggregating multiple sample feature weights. The aggregation of sample feature weights can be done at the client system, for example, to obtain client-side feature weights for the training samples on that client system, which can be an aggregation of multiple sample feature weights. The client-side feature weights can then be further aggregated on the server. Alternatively, the client system can send its sample feature weights to the server, allowing the server to directly aggregate the sample feature weights.

[0148] Sample feature weights can be calculated by changing one of the feature values. Sample feature weights can indicate whether the model output has changed, or how much the features need to be changed before the model output changes, and so on.

[0149] A particularly good source of sample feature weights is by applying so-called interpretability algorithms to the training samples and the model. Interpretability algorithms indicate which features are important for the model to draw conclusions. Interpretability algorithms can also be applied directly to the model and from which feature weights are determined. Interpretability algorithms are sometimes referred to as interpretable algorithms. For example, an interpretable algorithm that can be used is LIME, as described, for example, in the article “'Why Should I Trust You?' Explaining the Predictions of AnyClassifier” by Marco Tulio Ribeiro, Sameer Singh, and Carlos Guestrin, which is incorporated herein by reference; for example, Algorithm 1 can be applied. Another example of an interpretable algorithm that can be used is SHAP, as described, for example, in the article “A Unified Approach to Interpreting Model Predictions” by Scott M. Lundberg and Su-In Lee, which is incorporated herein by reference.

[0150] For example, in one embodiment, the client system can select one or more training samples from its client training set. This selection could be all training samples or a subset, such as a random subset. The client system can apply its algorithm to the selected training samples, for example, an interpretability algorithm, and obtain sample feature weights indicating the importance of features to the selected training samples. These sample weights can be combined into client feature weights, which can then be combined into aggregated feature weights. The latter can be performed by the server. This combination can be accomplished using a combination function, such as an averaging function.

[0151] In this embodiment, server 211 determines a base model, distributes the base model, and calculates aggregated models and aggregated feature weights. The aggregated weights provide important feedback to the client system. This process can also be iterative; for example, the aggregated model can be distributed, and then further aggregated models and further aggregated feature weights can be determined.

[0152] In embodiments, the base model (if used) and the aggregation model allow for more feature values ​​in the main feature set at their inputs. This main feature set may be larger, even much larger than the feature set used in the client training set, or even larger than the basic training set. This problem can be addressed using different methods.

[0153] To apply a model to training samples that do not indicate feature values ​​for a specific feature, alternative values ​​can be input. For example, an alternative value could be an interpolation. An interpolation could be a known average of the value, possibly introducing some noise. If the feature is used in some other training samples, missing values ​​can be interpolated from them, for example, using the average of the k nearest neighbors. Interpolation can be customer-specific. For example, consider a children's hospital that does not use the feature "age". In such a case, it would be better to use the average age of the children in that hospital rather than the average age of a potentially broader patient population.

[0154] The surrogate value can be a random value within a range. When the training samples are used again in the next training iteration, the surrogate value can be chosen again. In this embodiment, a surrogate value is chosen such that the feature weights of that feature converge to zero; for example, the feature is not important for prediction because the data is practically unavailable, so it should be important.

[0155] Another approach is to extend the model with additional inputs that indicate whether a certain value is available at the model's input for a specific value. The advantage of this approach is that the model can learn to handle missing values ​​on its own. For example, even for features available in the training samples, the model can be trained on training samples where, for some training iterations, the features are removed. This approach is better suited for situations using general-purpose models and relatively large amounts of training data. For example, the model can include a neural network. Some input lines of the neural network can represent feature values, while others represent the availability of values. For example, the neural network's input x can be used to input feature values, such as smoking or not smoking, while the input y can indicate whether input x indicates a value. If the input y indicates that the smoking variable is missing, the model will learn to ignore or insert the smoking variable. Such behavior can be trained by including samples with missing values ​​in the training. Such samples can be obtained by masking the features for that training iteration or by using (client-side) training samples that are missing values ​​in all cases.

[0156] Figure 2bAn example embodiment of server training system 212 is illustrated schematically. Server system 212 is similar to server system 211, except that server system 212 does not include feature weight determiner 240. The feature weights of the aggregated model are determined based on feature weights received from multiple clients. System 212 includes training unit 231 and base training set 210; these are advantageous because they ensure that client systems begin their training from a common starting point, which in turn ensures faster convergence. However, this is not mandatory; model parameters can also be directly averaged, or the base model can be obtained from another source. System 212 includes evaluation unit 232, allowing server 212 to be used to evaluate the model. While convenient, this is not mandatory either.

[0157] Figure 3a An example of an embodiment of the client training system 311 is illustrated schematically. The client system 311 can be configured to cooperate with an embodiment of the server 211. It will be understood that the client system 311 can be configured to operate as expected in an embodiment of the server system.

[0158] For example, client system 311 may include, for example, a client training set 310 in a client training set memory. One advantage is that the client training set does not need to be shared with other parties. Client system 311 includes model parameters 320. Model parameters can be obtained by training on the client training set. Model parameters can be obtained by receiving an initial base model. Model parameters 320 can be improved by local training on the client training set. For example, the client may include a training unit 331 to perform training algorithms, such as backpropagation, gradient descent, etc. Client system 311 may include an evaluation unit 332 for using the model. For example, evaluation unit 332 can use model parameters 320 to apply the model to a set of feature values. For example, evaluation unit 332 can be used for client purposes. For example, evaluation unit 332 can be used to predict the CVD risk of hospital clients.

[0159] Client device 311 may include model update unit 322 to generate model updates and send them to server 211. For example, model updates may be prepared periodically, or after a predetermined number of training iterations, etc. Model updates may include model parameters 320 or may include increments, such as the difference between the previous model received from server 211 and the current values ​​of the model parameters. Instead of model parameters, information indicating gradient descent may be sent.

[0160] Client device 311 may include a feature weight determiner 340. The feature weight determiner 340 is configured to determine the feature weights of the features used by client device 311. Feature weights only need to be computed for the features actually used by client device 311. For example, while the received model (e.g., a base model or aggregate model) may allow many features to be input into the model, a subset of these features (e.g., a subset of the main feature set) may not be represented in the client training set 310. Features for which client system 311 does not have training samples do not need to have feature weights determined because there is no data available for it. The client can use systems such as LIME or SHAP to compute feature weights. The client can also use other methods, such as determining how frequently the model output changes if a particular input changes. For example, given... One training sample and a binary input In this case, it can be The feature weights are calculated as the weights of the training samples when... by its complement The percentage of output that changes when a replacement is made.

[0161] Figure 3b An example of an embodiment of the feature set is illustrated schematically. Figure 3b Feature sets 351, 352, and 353 are shown in the figure.

[0162] For example, feature set 351 could be the main feature set, such as the feature set for configuring the base model and / or aggregate model. Figure 3b Feature set 351 shown is features 361-364. Preferably, the basic training set has some training data for each feature, but this is not required. For example, various techniques for missing feature values ​​can be used during the training of the base model. For example, the basic training can be arranged such that features without data in the basic training set have low weights, e.g., close to 0. Once the client updates the model, for example, using data with information about the missing features, the feature weights can move away from 0. Note that in the embodiment, if training continues in clients that do not use the features, the unused computed weights converge to 0; however, when a client reports its feature weights, it does not need to report the feature weights of unused features. For example, it can set the feature weights to 0. For example, it can report the feature weights but also indicate that they correspond to unused features. This allows the server to average only the clients that actually use the feature. The client can also report how many samples using a particular feature were used, which can be 0 for unused features.

[0163] For example, a first client system may support features of feature set 352, such as features 361, 362, and 364, but not 363. Similarly, a second client system may support features of feature set 353, such as features 361, 362, and 363, but not 364. Note that feature sets 352 and 353 overlap but are distinct. Note that both feature sets 352 and 353 are subsets of the main feature set 351; in this case, they are strictly subsets. Note that both feature sets 352 and 353 omit at least one feature from the main feature set. Client systems corresponding to feature sets 352 and 353 may use one of the techniques for missing feature values, for example, for features 363 and 364 respectively. Client systems corresponding to feature sets 352 and 353 do not require, or do not need to, determine the feature weights for features 363 and 364 separately.

[0164] Below are some further examples. For example, systems 100, 200, 211, 212, and / or 311 can be configured for these examples. Note that these examples contain specific choices that can be varied and / or are unnecessary.

[0165] For example, one embodiment includes the following elements:

[0166] Server: Trains a base model on a base training set and distributes the base model to clients.

[0167] The base model allows a set of primary features to be used as input, even if the base model may not use all features or may not have been trained for all features. For example, 20 to 30 features may be in the primary feature set; more or fewer features are also possible.

[0168] Missing feature values ​​can be set as substitute values, such as 0, interpolated values, etc., or represent the missing signal. Preferably, the impact of missing features on the prediction is neutralized.

[0169] For example, not all features need to be represented in the basic training data. The basic set may be small.

[0170] Customer: To further train the base model locally based on local training data.

[0171] Local training data may not use all features from the main feature set. For example, a client-side feature set might have 10 to 20 features. The actual number may be larger or smaller, depending on the details of the use case.

[0172] For servers, lost feature values ​​can be handled in various ways, such as setting them as replacement values, setting them as lost, and so on.

[0173] Local training data can use features from the main feature set that are not represented in the basic training data. Local training data can also use features from the main feature set that are used by some other client systems.

[0174] The client sends a model update, indicating the improved parameter values ​​to the server.

[0175] Server: Aggregation, for example, receiving parameter updates on average and updating the base model to the updated model.

[0176] Server: Distributes updated models to clients

[0177] Client: Evaluate the features of the updated model to determine which features are important.

[0178] For example, the updated model can be applied to multiple client training samples, and the resulting predictions can be interpreted.

[0179] For example, input x produces output y. By changing the values ​​in x and observing the changes in y, the relative importance of features in x can be determined. This can be done for multiple inputs x. Input x can be selected from the client's training set.

[0180] The client will send feature weights to the server.

[0181] Alternatively or additionally, feature weights can be determined on the server, especially if all features have representative training samples.

[0182] Server: For example, by averaging the received feature weights, global information about the relative importance of the features can be obtained.

[0183] Server: Passes the information obtained from the feature weights to the client.

[0184] For example, a server can send signals to at least one of multiple client devices based on the aggregated feature weights of the aggregated model's features. For example, the server can send one or more, or all, aggregated feature weights. For example, the server can indicate to the clients which currently unused features are important for improving the model output, such as improving predictions.

[0185] Steps 2-7 can be repeated multiple times.

[0186] For example, in this embodiment, the model is a multiple regression model, such as a linear multiple regression model. The advantage of this choice is that a base model is not required. For example, in this embodiment, the client trains the model on its client training set, which is essentially the client base model. These models can be sent to a server, which can aggregate them. For example, a master feature set can be built on a per-client feature set. The model parameters can be obtained by a weighted average of the parameters of the clients using those features. The client can use the aggregated model by setting the parameters of unused features to zero. Feature weights can be obtained directly from the parameters, for example, by multiplying the feature's parameters by the average of that feature. For example, this can be conveyed if the model parameters are high, or if the average of the product of the parameters and feature values ​​is high in the aggregated model but not used by the client, for example, is 0. Logistic multiple regression can be used instead of linear multiple regression.

[0187] In this embodiment, the model is a medical model. The input to the model can be a set of medically relevant data, such as weight, age, height, smoking, diabetes, etc. The output can be a disease probability, such as the probability or likelihood that a patient has the disease or is at risk of developing it. The model can also be used for purposes other than prediction, such as image segmentation or classification. For example, in this embodiment, the model's input includes multidimensional data, such as images obtained from an imaging device like a camera, and multiple values ​​of 1-dimensional or 0-dimensional data. For example, images and other medical data, such as age, blood pressure, smoking, diabetes, etc. The model's output can be image-related, such as image segmentation or image classification. Additional non-image features can be different. For example, some client sites may or may not use some or all of these features. Feature weight aggregation of additional features may prove that some of these features are relevant to obtaining the correct output, while others are not.

[0188] Aggregation models do not necessarily require integrating model updates into a single model; for example, federated learning or other distributed learning algorithms can be used. In an alternative, client models are collected within an ensemble model. Client models can be selected based on performance or complementarity. For instance, the top-performing model in the ensemble can be chosen as the best performing model; subsequent models can be selected as those performing well on the training samples, even if the current ensemble performs poorly on those samples. Adding models to the ensemble can be stopped when additional models no longer improve predictions, when a predetermined performance target has been reached, or both. Local training still offers advantages, even if the base training set is large enough to allow for good performance evaluation; for example, it prevents overfitting, distributes computation, and avoids transferring large amounts of training data. An advantage of ensemble aggregation is the ease with which heterogeneous models can be integrated; for example, neural networks can be combined with logical multivariate models—in this embodiment, the models used by the client and server systems are the same, even if they are aggregated as a whole rather than integrated.

[0189] For example, in one embodiment, the server receives multiple trained models from multiple client systems (e.g., a hospital) and creates an ensemble model from these models. For instance, the ensemble model may include a compositing component; for example, the compositing component may be trained to receive input from multiple models in the ensemble and produce a single output. Statistical compositing is also possible. For example, the ensemble model may use AdaBoosting.

[0190] For ensemble models, feature weights can also be computed. For example, model-agnostic interpreters, such as Lyme, SHAP, etc., can be used because the interpreter does not require assumptions about specific underlying model techniques.

[0191] refer to Figure 4a and Figure 4b Further embodiments are shown. Figure 4a An example of an embodiment of the training system is illustrated schematically. Figure 4a The diagram shows server 400, such as a server system or server device, and multiple clients; clients 421, 422, and 423 are shown.

[0192] Server 400 includes various feature units, such as hardware and / or software configured for features. For example, in one example, server 400 includes unit 411 for receiving aggregator packets. The aggregator packets, which include information indicating how previous iterations of the model can be improved relative to the local training data available at the client, are received from a client device. Unit 412 is configured to aggregate the model. The model implemented in unit 412 is updated using the aggregator packets received from the client. Unit 413 is configured as a model interpreter. The model interpreter determines which input features are important for the model's current iteration's predictions. Unit 414 is configured as a feature discriminator. The feature discriminator determines what conclusions should be drawn from the information in the model interpreter and communicates this to the client. For example, the discriminator can select clients that have failed to utilize important features and communicate this information to those clients. Unit 415 is configured to transmit feature indications to the client. Figure 4a This illustrates information flowing from the client to the server, such as model updates and client feature weights, and information flowing from the server to the client, such as aggregated models and aggregated weights, or selected features.

[0193] For example, this embodiment can use federated learning. Federated learning (FL) enables clients (e.g., hospitals) to collaboratively learn a shared predictive model without moving data outside the client (e.g., the hospital). Each site's model learns the available characteristics of that particular site. The aggregated model is sent back to each client for further training. Interpretable AI, such as methods and techniques in the application of artificial intelligence (AI) technologies, allows human experts to understand the results of the solution and can be used to determine the relative importance of input features.

[0194] In a distributed environment, one or more features considered during training at one location may be lost at other locations. It is necessary to provide reasonable suggestions for the features considered in the aggregated model so that another site can begin to capture important missing features.

[0195] Interpretability algorithms can be applied to aggregation models, such as those derived from federated learning. These algorithms can be used to explain the model and determine the underlying principles behind the predictions made within the aggregation model. Model performance can be improved for clients who begin incorporating important but missed features (e.g., by capturing them). This can also reduce the time required for in-situ training.

[0196] When using federated learning and similar methods in real-world settings, challenges arise. While federated learning allows for distributed learning, it still requires uniform data across clients. In practice, this is often not the case. In this example, interpretability techniques are used to interpret the model and extract key features captured in the final model. This knowledge can then be transferred to participating sites so they can begin capturing missing key features. Such techniques not only improve model performance but also reduce the time required for training at each location; training on the dataset makes prediction easier, requiring less time. Therefore, the possibility that features considered during training at one location may be missing at another is addressed.

[0197] Training at one location may involve a set of locations participating in model training. Sites can be configured to send back updated gradients or weights, etc., after local training. A server, also known as a coordinator server, can be configured to manage the distributed learning workflow and coordinate with the sites. The coordinator server can be hosted locally or located in the cloud.

[0198] Model updates, model aggregation, and client feature weight sending can be synchronous, but this is not necessary. In fact, especially when there are many clients, it's beneficial to avoid having all clients participate in all steps simultaneously. For example, clients can send model updates when they have performed sufficient training. Other clients may not yet be ready to send updates. When the server has a sufficient number of model updates, it can prepare to aggregate the model without waiting for all clients to send updates. Model updates received for previous iterations of the model can still be aggregated, for example, weighted. When training is complete, the final model can be generated after the final round of training. This model can be stored on local disk or in the cloud, etc.

[0199] The model interpreter module can be used to interpret the model and determine which features play a significant role in the model's predictions. Model interpreters can be used to determine the importance of features. Model interpretability, also known as model interpretability, provides an overall view of the model's performance. For example, it can help people better understand why some model predictions are correct while others are incorrect, for instance, by tracing the model's decision path. A model interpreter can provide an overview of which features in the dataset contribute to the model's decision-making. The importance of a feature can be viewed as its impact on the model's predictions. Based on importance, suggestions can be provided to include features from sites that do not capture that particular feature. Various known model interpreters are available, such as Lyme and SHAP, which can help interpret model decisions.

[0200] For some models, such as logistic regression, coefficients or parameters can be obtained as feature importance scores. A higher score indicates greater importance associated with that feature, and vice versa. These coefficients provide a global overview of the overall feature importance across the entire dataset.

[0201] Figure 4b An example of an embodiment of the training system is illustrated schematically. Figure 4b The diagram illustrates two participating sites: sites 430 and 440, for example, clients; there could be more participating sites. For instance, each site could have a model for predicting cardiovascular disease. Several cardiovascular disease risk prediction models have been developed for different populations over the past decade, but to further improve the models, participating sites (e.g., sites 430 and 440) want to collaborate to obtain a better model. Federated learning algorithms can be used to train cardiovascular disease risk prediction models at different locations.

[0202] exist Figure 4b The diagram illustrates customer models 431 and 441 for each site, such as models received from the server but further trained based on local data; customer predictions 432 and 442, such as predictions obtained by applying the customer model to local training samples; and client interpreters 433 and 443. The client interpreters can use one or more predictions to determine feature weights 434 and 444, such as time weights.

[0203] For example, feature weight 434 could be:

[0204] 40% of hypertension

[0205] 10% of age

[0206] 30% of diabetes

[0207] 10% exercise system

[0208] 10% family history

[0209] For example, feature weight 435 could be

[0210] 25% of hypertension

[0211] 25% of smokers

[0212] 25% of diabetic patients

[0213] 10% of age

[0214] 5% exercise system

[0215] 10% family history

[0216] Similar outputs can be generated after local training at other sites. Feature weights 434 and 444 can be sent to an aggregator, such as a server, for aggregation, possibly along with model updates. Multiple local training and aggregation cycles may occur until a final model is obtained at some point. For example, at site 450, such as the server or one of sites 430 or 440, or even further away, the final aggregated model 451 is available. If interpreter 453 is applied to predict 452 to obtain feature weights 454, they may differ from the initial weights. For example, feature weights 454 could be:

[0217] 30% of hypertension

[0218] 30% of smokers

[0219] 10% of age

[0220] 20% of diabetic patients

[0221] 5% exercise system

[0222] 5% family history

[0223] Note that smoking was not used as a feature at site 430. Also note that the prevalence of family history was 10%, which has now decreased to 5%. This is partly due to further training, but also because the importance of smoking has increased. It could be suggested that site 430 begin capturing smoking features, as not using it might weaken the model's predictive power at site 430.

[0224] In various embodiments of server and client systems, such as systems 200 and 100, the communication interface can be selected from a variety of alternatives. For example, the interface could be a network interface to a local area network (LAN) or wide area network (e.g., the Internet), a storage interface to internal or external data storage, an application interface (API), etc. These systems can have a user interface that may include well-known elements such as one or more buttons, a keyboard, a display, a touchscreen, etc. The user interface can be configured to adapt to user interaction for configuring the system, training the network on a training set, or applying the system to new data, etc.

[0225] The memory can be implemented as electronic memory, such as flash memory, or magnetic memory, such as hard disks. The storage device may include multiple discrete memories that together constitute storage devices 160, 260. The memory may include temporary memory, such as RAM. Storage may be cloud storage.

[0226] Server and client systems can each be implemented in a single device. For example, in one embodiment, the client system is a client device, while the server system is implemented in the cloud, for example, distributed across multiple computers. Typically, server and client systems include microprocessors that execute appropriate software stored in the system; for example, this software may have been downloaded and / or stored in appropriate memory, such as volatile memory like RAM or non-volatile memory like flash memory. Alternatively, the system can be implemented wholly or partially in programmable logic, for example, as a field-programmable gate array (FPGA). These systems can be implemented wholly or partially as so-called application-specific integrated circuits (ASICs), for example, integrated circuits (ICs) customized for their specific purpose. For example, the circuitry can be implemented using CMOS, for example, using hardware description languages ​​such as Verilog, VHDL, etc. In particular, server and client systems can include circuitry for evaluating models, for example, neural networks.

[0227] Processor circuitry can be implemented in a distributed manner, for example, as multiple sub-processor circuits. Memory can be distributed across multiple distributed sub-memories. Some or all of the memory can be electronic memory, magnetic memory, etc. For example, memory can have volatile and non-volatile components. Some storage may be read-only.

[0228] Figure 5 An example embodiment of a server training method 500 is illustrated schematically. Method 500 can be a computer-implemented training method for training a model. Method 500 includes:

[0229] Multiple model updates are received from multiple client devices (510), each model update representing improved model parameters during training iterations run by the client devices on corresponding client training sets. The training samples in the client training sets indicate values ​​of multiple features, with at least some from the multiple client training sets indicating values ​​of different features.

[0230] Multiple model updates are aggregated (520) to obtain an aggregated model, which is arranged to receive multiple feature values ​​representing multiple features.

[0231] Obtain the feature weights (530) of the aggregation model, which represent the relative importance of multiple features in the output of the aggregation model.

[0232] Based on the aggregate feature weights of the aggregate model's features, a signal (540) is sent to at least one of the multiple client devices.

[0233] Figure 6 An example of an embodiment of client-side training method 600 is illustrated schematically. Method 600 may be implemented by a computer. Method 600 includes:

[0234] Improvements (610) to model parameters in training iterations run on client training sets, where training samples in the client training set indicate values ​​of multiple features, and at least some other client training sets indicate values ​​of different features.

[0235] Send a model update (620) to the training system, representing the improved model parameters.

[0236] The method also includes:

[0237] Receive (630) the aggregation model from the training system, determine the client feature weights of the aggregation model, and send the client feature weights to the training system, and / or

[0238] Receive (640) a signal indicating a specific feature not indicated in the client training set, wherein the client training set does not indicate the value of the specific feature and the relative importance of the specific feature is above a threshold.

[0239] For example, the training method can be a computer-implemented method. For instance, accessing training data and / or receiving model updates, client feature weights, sending aggregated data, and sending feature-related data can be accomplished using communication interfaces, such as electronic interfaces, network interfaces, etc. For instance, parameters can be stored or retrieved from electronic storage devices, such as memory, hard disk drives, etc. For example, network parameters. For instance, applying the neural network to the training data and / or adjusting the stored parameters to train the network can be accomplished using electronic computing devices, such as computers.

[0240] During training and / or application, a neural network may have multiple layers, which may include, for example, convolutional layers. For example, a neural network may have at least 2, 5, 10, 15, 20, or 40 hidden layers, or more, etc. The number of neurons in a neural network may be, for example, at least 10, 100, 1000, 10000, 100000, 100000, or more, etc.

[0241] It will be apparent to those skilled in the art that many different ways are possible to perform this method. For example, the steps may be performed in the order shown, but the order of the steps may be changed, or some steps may be performed in parallel. Furthermore, other method steps may be inserted between steps. The inserted steps may represent an improvement on the method described herein, or they may be unrelated to the method. For example, some steps may be performed at least partially in parallel. Moreover, a given step may not be fully completed before the next step begins.

[0242] Embodiments of this method can be executed using software that includes instructions for causing a processor system to execute method 500 or 600. The system method may include all or part of methods 500 and 600. Methods 500 and 600 can be extended using some of the options discussed herein. The software may only include those steps taken by a specific sub-entity of the system. The software can be stored in a suitable storage medium, such as a hard disk, floppy disk, memory, optical disk, etc. The software can be transmitted as a signal along a wired or wireless route or using a data network (e.g., the Internet). The software can be downloaded and / or used remotely on a server. Embodiments of this method can be executed using a bitstream configured to configure programmable logic, such as a field-programmable gate array (FPGA), to execute the method.

[0243] It should be understood that the currently disclosed subject matter also extends to computer programs, particularly computer programs on or in a carrier, suitable for putting the currently disclosed subject matter into practice. The program may be in the form of source code, object code, intermediate source code, and object code, for example, in a partially compiled form, or any other form suitable for implementing embodiments of the method. Embodiments relating to computer program products include computer-executable instructions corresponding to each processing step of at least one of the methods described. These instructions may be subdivided into subroutines and / or stored in one or more files that may be statically or dynamically linked. Another embodiment relating to computer program products includes computer-executable instructions corresponding to each device, unit, and / or portion of at least one system and / or product described.

[0244] Figure 7a A computer-readable medium 1000 having a writable portion 1010 and a computer-readable medium 1001 also having a writable portion are shown. The computer-readable medium 1000 is shown in the form of an optically readable medium. The computer-readable medium 1001 is shown in the form of an electronic memory, in such a case, a memory card. According to one embodiment, the computer-readable media 1000 and 1001 can store data 1020, wherein the data can indicate instructions that, when executed by a processor system, cause the processor system to perform an embodiment of a server or client method. The computer program 1020 can be implemented on the computer-readable medium 1000 as a physical marker or by magnetization of the computer-readable medium 1000. However, any other suitable embodiments are contemplated. Furthermore, it should be understood that although the computer-readable medium 1000 is shown herein as an optical disc, the computer-readable medium 1000 can be any suitable computer-readable medium, such as a hard disk, solid-state storage, flash memory, etc., and can be non-recordable or recordable. The computer program 1020 includes instructions for causing the processor system to perform the server or client method.

[0245] Figure 7b A schematic diagram of a processor system 1140 according to an embodiment of a server or client system is shown. The processor system includes one or more integrated circuits 1110. Figure 7b The architecture of one or more integrated circuits 1110 is schematically illustrated. Circuit 1110 includes a processing unit 1120, such as a CPU, for running computer program components to perform methods and / or implement modules or units thereof according to embodiments. Circuit 1110 includes a memory 1122 for storing program code, data, etc. A portion of the memory 1122 may be read-only. Circuit 1110 may include a communication element 1126, such as an antenna, a connector, or both, etc. Circuit 1110 may include an application-specific integrated circuit 1124 for performing some or all of the processing defined in the method. Processor 1120, memory 1122, application-specific IC 1124, and communication element 1126 may be interconnected via interconnect 1130 (e.g., a bus). Circuit 1110 may be arranged to perform contact and / or contactless communication using antennas and / or connectors, respectively.

[0246] For example, in one embodiment, the processor system 1140 (e.g., a server or client device) may include processor circuitry and memory circuitry, the processor being configured to execute software stored in the memory circuitry. For example, the processor circuitry may be an Intel Core i7 processor, an ARM Cortex-R8, etc. In another embodiment, the processor circuitry may be an ARM Cortex-M0. The memory circuitry may be ROM circuitry or non-volatile memory, such as flash memory. Alternatively, the memory circuitry may be volatile memory, such as SRAM memory. In the latter case, the device may include a non-volatile software interface, such as a hard disk drive, a network interface, etc., arranged to provide software.

[0247] Although device 1140 is shown as including one of each described component, in various embodiments, the various components may be repeated. For example, processor 1120 may include multiple microprocessors configured to independently execute the methods described herein, or configured to execute steps or subroutines of the methods described herein, such that multiple processors cooperate to implement the features described herein. Furthermore, in the case of device 1140 implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, processor 1120 may include a first processor in a first server and a second processor in a second server.

[0248] It should be noted that the above embodiments are illustrative and not limiting of the subject matter currently disclosed, and those skilled in the art will be able to devise many alternative embodiments.

[0249] In the claims, any reference numerals in parentheses should not be construed as limiting the claims. The use of the verb "comprising" and its variations does not exclude the presence of elements or steps other than those described in the claims. The article "a" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as "at least one" preceding a list of elements indicate the selection of all elements or any subset of elements from the list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The subject matter currently disclosed can be implemented by hardware comprising several different elements and by a suitably programmed computer. In device claims that enumerate several parts, several of these parts can be implemented by the same hardware. The fact that certain measures are referenced in mutually different dependent claims does not mean that a combination of these measures cannot be used advantageously.

[0250] In the claims, reference numerals enclosed in parentheses refer to reference numerals in the accompanying drawings of exemplary embodiments or formulas of embodiments, thus increasing the comprehensibility of the claims. These references should not be construed as limiting the claims.

Claims

1. A computer-implemented server method (500) for training a model, the method comprising: Multiple model updates are received (510) from multiple client systems (101-103), each model update representing the improved model parameters (320) during training iterations run by the client systems on corresponding client training sets (310). The training samples in the client training sets indicate values ​​of multiple features, and at least some of the client training sets indicate values ​​of different features. The multiple model updates are aggregated (520) to obtain an aggregated model (412), the aggregated model being arranged to receive multiple feature values ​​representing multiple features, wherein the aggregated model is arranged to apply the aggregated model to training samples that indicate the values ​​of multiple features but do not indicate the value of at least one missing feature, wherein applying the aggregated model includes: inputting interpolated values ​​of the missing features, and / or inputting a signal indicating that no feature value is indicated for the feature. Obtain feature weights (530) for the aggregation model, wherein the feature weights for the aggregation model represent the relative importance of the plurality of features to the output of the aggregation model, wherein each feature weight in the feature weights for the aggregation model is calculated only based on the feature weights of the corresponding features of the client systems that use the corresponding features. Based on the calculated feature weights for the features of the aggregation model, a signal (540) is sent to at least one of the plurality of client systems.

2. The method according to claim 1, wherein, The aggregation model is configured to receive training samples from a client training set that indicate values ​​of multiple features as input feature values ​​to a main feature set, wherein the multiple features are a subset of the main feature set, and at least one client training set indicates feature values ​​of features that are an exact subset of the main feature set.

3. The method according to claim 1 or 2, comprising: Select the following specific features and client training set: the client training set does not indicate the value of the specific feature, and the relative importance of the specific feature is higher than a threshold. Sending the signal includes sending a signal indicating the specific feature to the client system corresponding to the selected client training set.

4. The method according to claim 1 or 2, comprising distributing the aggregation model to the plurality of client systems.

5. The method according to claim 4, wherein, Obtaining the feature weights for the aggregation model includes: receiving multiple client feature weights for the aggregation model determined by multiple clients, and aggregating the client feature weights.

6. The method according to any one of claims 1, 2, and 5, wherein, Obtaining feature weights includes: For multiple training samples, The aggregation model is applied to the feature values ​​in the training samples to obtain the model output. An interpretability algorithm is applied to obtain sample feature weights that indicate the relative importance of the feature values ​​for the training samples. The sample feature weights are combined to obtain the feature weights.

7. The method according to any one of claims 1, 2, and 5, comprising: A base model is trained on a basic training set and distributed to the multiple client systems. The model update is an update of the base model, which is configured to receive feature values ​​from a main feature set. The training samples in the client training set indicate the values ​​of multiple features, which are subsets of the main feature set.

8. The method according to claim 6, wherein, The training samples are the training samples in the client training set.

9. The method according to claim 7, wherein, The training samples are training samples from the client training set, and / or The training samples are the training samples in the basic training set.

10. The method according to any one of claims 1, 2, 5, 8, and 9, comprising: One or more iterations of the following operations: Receive multiple model updates from multiple client systems regarding the aggregated model received by the client systems. Aggregate the multiple model updates to obtain a further aggregated model. Obtain the feature weights of the further aggregation model.

11. The method according to any one of claims 1, 2, 5, 8, and 9, wherein, Aggregating the multiple model updates includes: Apply the average value to the multiple model updates, and / or Select two or more model updates from the plurality of model updates, and configure the overall model based on the selected model updates.

12. The method according to any one of claims 1, 2, 5, 8, and 9, wherein, The model is a medical model configured to receive medical feature values ​​as input and / or predict medical conditions.

13. A computer-implemented client method (600) for training a model, the method comprising: The model parameters are improved (610) during training iterations run on the client training set, where training samples in the client training set indicate values ​​of multiple features, and at least some client training sets in other client training sets indicate values ​​of different features. Send a model update (620) to the training system, representing the improved model parameters. The method further includes: The training system receives (630) an aggregation model, wherein the aggregation model is configured to apply the aggregation model to training samples indicating values ​​of multiple features and not indicating values ​​of at least one missing feature, wherein applying the aggregation model includes: inputting interpolated values ​​of the missing features, and / or inputting a signal indicating that no feature value is indicated for the feature; and wherein each feature weight in the feature weights for the aggregation model is calculated only based on the feature weights of the corresponding feature in the client system using the corresponding feature, and Determine the client feature weights for the aggregation model, and send the client feature weights to the training system, and / or Receive (640) a signal indicating that the following specific features are not indicated in the client training set: the client training set does not indicate the value of the specific feature, and the relative importance of the specific feature is above a threshold.

14. A server system for training a model: the server system comprising: The communication interface is configured for digital communication with multiple client systems. Processor system, which is configured to: Multiple model updates are received from multiple client systems (510), each model update representing improved model parameters obtained by the client systems during training iterations run on corresponding client training sets. The training samples in the client training sets indicate values ​​of multiple features, and at least some of the client training sets indicate values ​​of different features. The multiple model updates are aggregated (520) to obtain an aggregated model, the aggregated model being arranged to receive multiple feature values ​​representing multiple features, wherein the aggregated model is arranged to apply the aggregated model to training samples that indicate values ​​of multiple features but do not indicate values ​​of at least one missing feature, wherein applying the aggregated model includes: inputting interpolated values ​​of the missing features, and / or inputting a signal indicating that no feature value is indicated for the feature. Obtain feature weights (530) for the aggregation model, wherein the feature weights for the aggregation model represent the relative importance of the plurality of features to the output of the aggregation model, wherein each feature weight in the feature weights for the aggregation model is calculated only based on the feature weights of the corresponding features of the client system using the corresponding features, and Based on the calculated feature weights for the features of the aggregation model, a signal (540) is sent to at least one of the plurality of client systems.

15. A client system for training a model, the client system comprising: A communication interface, configured for digital communication with the server system, and Processor system, which is configured to: The model parameters are improved (610) during training iterations run on the client training set, where training samples in the client training set indicate values ​​of multiple features, and at least some client training sets in other client training sets indicate values ​​of different features. Send a model update (620) to the training system, representing the improved model parameters. The processor system is further configured to: The training system receives (630) an aggregation model, wherein the aggregation model is configured to apply the aggregation model to training samples indicating values ​​of multiple features and not indicating values ​​of at least one missing feature, wherein applying the aggregation model includes: inputting interpolated values ​​of the missing features, and / or inputting a signal indicating that no feature value is indicated for the feature; and wherein each feature weight in the feature weights for the aggregation model is calculated only based on the feature weights of the corresponding feature in the client system using the corresponding feature, and Determine the client feature weights for the aggregation model, and send the client feature weights to the training system, and / or Receive (640) a signal indicating that the following specific features are not indicated in the client training set: the client training set does not indicate the value of the specific feature, and the relative importance of the specific feature is above a threshold.

16. A transient or non-transient computer-readable medium (1000) comprising data (1020) representing instructions that, when executed by a processor system, cause the processor system to perform the method according to any one of claims 1-13.

Images