Self-organizing modular neural network construction method for smart internet of things environment

Abstract

This application belongs to the field of distributed edge computing technology for the Internet of Things (IoT). This application provides a method for constructing self-organizing modular neural networks for intelligent IoT environments. First, specialized modules are constructed through module specialization bias, route-induced specialization learning, and partitioned static signature initialization. Second, input-driven hierarchical routing generates routing decisions from input features and decouples semantic module selection and execution constraints, thereby achieving efficient and adaptive routing under heterogeneous deployment conditions. Finally, through reliability-aware module collaboration and selective aggregation, efficient module collaborative decision-making is achieved without central coordination, realizing decentralized collaborative training with module function differentiation, efficient routing, and low communication overhead on resource-constrained heterogeneous AIoT devices.

Description

Technical Field

[0001] This disclosure relates to the field of distributed edge computing technology for artificial intelligence and the Internet of Things (AIIoT), and more particularly to a method for constructing self-organizing modular neural networks for intelligent IoT environments. Background Technology

[0002] With the rapid development of smart Internet of Things (IoT) technology, the number of Artificial Intelligence of Things (AIoT) devices has surged. AIoT devices combine sensing capabilities with on-device machine learning, utilizing deep learning models to continuously collect rich and diverse data streams from their surroundings, while simultaneously performing local data processing and inference to meet the application requirements of low latency, high privacy, and low bandwidth. Compared to traditional cloud-centric approaches, this paradigm shift offers significant advantages, including reduced latency, enhanced privacy, reduced bandwidth requirements, and increased operational autonomy.

[0003] Deploying complex deep learning models in resource-constrained AIoT devices presents significant challenges: 1) Modern neural networks' demands on computing resources, memory capacity, and energy consumption exceed the capabilities of most AIoT devices, resulting in a severe mismatch between resource requirements and device capabilities. 2) Traditional monolithic neural networks employ fixed computation graphs, making them difficult to adapt to the diverse tasks of the AIoT environment. Model compression techniques are prone to accuracy loss and lack versatility. 3) Existing modular neural networks require manual design of module boundaries, lack self-organizing capabilities under distributed training, suffer from high communication overhead and low flexibility, and cannot meet the decentralized deployment requirements of AIoT devices.

[0004] In existing solutions, Hybrid Expert Models (MoE) dynamically select expert modules based on input features to achieve module reuse, but they suffer from circular dependencies and computational redundancy. Distributed methods such as federated learning do not fully integrate modular architectures, resulting in low parameter synchronization efficiency. Therefore, there is an urgent need for a neural network framework with self-organizing modularity and an efficient decentralized collaboration mechanism to adapt to resource-constrained AIoT environments.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this disclosure is to provide a method for constructing a self-organizing modular neural network for a smart Internet of Things (IoT) environment, thereby overcoming, to at least some extent, one or more problems caused by the limitations and defects of related technologies.

[0007] According to embodiments of this disclosure, a method for constructing a self-organizing modular neural network (i.e., BrickNN) for a smart Internet of Things (IoT) environment is provided, comprising: Step S1: Constraint-guided module construction A learnable specialized bias vector is introduced for each Brick module, enabling each Brick module to generate a structured bias in a shared latent representation space, thus breaking the parameter symmetry. For each Brick module, a partitioned static signature vector is calculated based on the category anchor representation; the static signature vector remains fixed throughout the training process and is only used for cross-heterogeneous AIoT device module matching. By jointly optimizing the module classification loss and the route supervision loss, and using the route assignment to determine the sample attribution, the functional differentiation of each Brick module is driven in different semantic subspaces. Step S2: Hierarchical routing based on input The learnable query network takes the latent representation generated by the shared encoder as input and directly generates a global routing weight vector for the entire module set through softmax transformation. The routing decision does not depend on the forward output of any module. The global routing weight vector is normalized and projected onto a subset of locally available modules of the current heterogeneous AIoT device to obtain the local routing weight; The final prediction is obtained by weighting and aggregating the outputs of each module based on the local routing weights. Step S3: Task-Aware Decentralized Collaboration After each global training round, each heterogeneous AIoT device broadcasts the static signature vector of its Brick module to its neighboring heterogeneous AIoT devices; A joint score is calculated for each local module and each neighbor candidate module. The joint score is composed of a weighted sum of the signature cosine similarity and the module performance reliability score. The top K candidate modules that exceed the compatibility threshold are selected from the joint scores in descending order to form a module collaboration set; The local module parameters are updated by weighting and aggregating the local reliability weight with the reliability scores of each module in the module collaboration set. Synchronize the shared encoder parameters of various heterogeneous AIoT devices.

[0008] Furthermore, self-organizing modular neural networks for intelligent IoT environments are used as a basis for... A distributed AIoT system consisting of heterogeneous AIoT devices, denoted as ______. ; Each heterogeneous AIoT device Holding local datasets And by the resource triplet Describe its resource characteristics; among which, For heterogeneous AIoT devices Local computing power For heterogeneous AIoT devices The achievable communication rate, For heterogeneous AIoT devices Storage capacity; Each heterogeneous AIoT device deploys a set of modules. ,common Each of the Brick modules is a module. Learning from the latent representation space To the task prediction space The mapping; where, For the dimension of the potential representation, This represents the number of task categories.

[0009] Furthermore, step S1 specifically includes: For each Brick module Introducing independent, learnable specialized bias vectors Overlay it onto the shared encoder Latent representation of the output After being processed by a transformation function, the Brick module is obtained. The middle representation ; intermediate representation Send to Brick module Predicting head The obtained output prediction : Based on local dataset Samples of each category The mean of the output of all samples of this category after forward propagation through the shared encoder is calculated to obtain the category anchor representation vector. ; For each Brick module Introducing partition mask vector Activate and assign to the Brick module Category set The corresponding latent representation dimension is used, and the remaining dimensions are set to zero. Representing category anchors After element-wise multiplication with the partition mask Normalization yields the Brick module. static signature vector ; Construct a classification loss that includes modules and routing supervision loss joint loss function ; By analyzing the joint loss function Perform reverse propagation to jointly update module parameters, encoder parameters, and routing network parameters.

[0010] Furthermore, shared encoders Input sample Mapping to latent representation :

[0011] Intermediate representation for:

[0012] in, For transformation function, For independent, learnable, specialized bias vectors; Output prediction for:

[0013] Category anchor representation vector for:

[0014] in, For category The sample set, Its sample size, Forward mapping function of shared encoder; Brick module static signature vector for:

[0015] in, This indicates element-wise multiplication. express Normalization operation, For Brick module The representative category of the assigned category; Module classification loss for:

[0016] in, Indicates in the device Local dataset Above all samples Seeking expectations, For Brick module The representative category of the assigned category, For indicator functions, The routing weight assigned to module m by the current input in the routing network. For the task loss function, For Brick module The mapping output of the latent representation, The true labels for the samples; Route supervision loss for:

[0017] in, To query the network's output logits vector for the latent representation, This is the index of the target module corresponding to the true label y of the sample. The cross-entropy loss function is based on this. Joint loss function for:

[0018] in, Weighting coefficients used to control the strength of route supervision.

[0019] Furthermore, step S2 specifically includes: Through a learnable query network The latent representation of the shared encoder output The data is mapped to a route score vector, then normalized using the softmax function to generate a global route weight vector that satisfies the probabilistic simplex constraint. ; For heterogeneous AIoT devices Locally available module subset , global route weight vector Components in In this subset Renormalization is performed on the top to obtain the local route weight. ; The final prediction is obtained by weighting and aggregating the outputs of each module based on the local routing weights.

[0020] Furthermore, the global routing weight vector for:

[0021] in, The Each component Brick module The weights selected under the current input satisfy the following conditions: and ; Local route weight for:

[0022] in, The module index for summation traversal.

[0023] Furthermore, step S3 specifically includes: For local heterogeneous AIoT devices Brick module on Neighbor candidate modules Calculate the joint score ; Based on joint scoring First, filter out those with scores no lower than the compatibility threshold. The candidate modules constitute the candidate set. ; From the candidate set Select the one with the highest joint score The candidate modules constitute the module collaboration set. ; heterogeneous AIoT devices Reliability weight Collaboration with modules Reliability scores of each candidate module The parameters of the local module and the collaborative module are weighted and averaged to update the module parameters.

[0024] Furthermore, joint scoring for:

[0025] in, For Brick module static signature vector With candidate modules static signature vector Cosine similarity between them: ; Candidate module Reliability rating: , Candidate module Classification accuracy on its local validation set; This is a balance coefficient between the similarity component and the reliability component; The module parameter update process is as follows:

[0026] in, Candidate module The parameters.

[0027] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects: In the embodiments of this disclosure, the above method, on the one hand, firstly, constructs specialized modules through module specialization bias, route-induced specialization learning, and partitioned static signature initialization. Secondly, input-driven hierarchical routing generates routing decisions from input features and decouples semantic module selection and execution constraints, thereby achieving efficient and adaptive routing under heterogeneous deployment conditions. Finally, through reliability-aware module collaboration and selective aggregation, efficient module collaborative decision-making is achieved without central coordination, realizing decentralized collaborative training with module function differentiation, efficient routing, and low communication overhead on resource-constrained heterogeneous AIoT devices. On the other hand, automatic module function differentiation, elimination of routing circular dependencies, and significant reduction of communication overhead are achieved without central coordination, resulting in a substantial improvement in the average accuracy and total training time for each device.

[0028] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0029] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0030] Figure 1 The diagram illustrates the steps of a method for constructing a self-organizing modular neural network for an intelligent Internet of Things (IoT) environment, as shown in an exemplary embodiment of this disclosure. Figure 2 This diagram illustrates a comparison of BrickNN deployment modes with other models in an exemplary embodiment of this disclosure. Figure 3 This diagram illustrates the workflow of the BrickNN framework in an exemplary embodiment of this disclosure. Figure 4 The diagram illustrates a comparison of the system efficiency of BrickNN with other methods on different datasets in an exemplary embodiment of this disclosure. Detailed Implementation

[0031] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0032] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0033] This example implementation first provides a method for constructing a self-organizing modular neural network for a smart Internet of Things (IoT) environment. This method can be applied to a terminal device, such as a mobile phone, personal digital assistant, laptop, tablet, smartwatch, or other mobile terminal [adjusted flexibly according to specific circumstances, such as a server]. Reference Figure 1 As shown, the method may include the following steps: Step S1: Constraint-guided module construction A learnable specialized bias vector is introduced for each Brick module, enabling each Brick module to generate a structured bias in a shared latent representation space, thus breaking the parameter symmetry. For each Brick module, a partitioned static signature vector is calculated based on the category anchor representation; the static signature vector remains fixed throughout the training process and is only used for cross-heterogeneous AIoT device module matching. By jointly optimizing the module classification loss and the route supervision loss, and using the route assignment to determine the sample attribution, the functional differentiation of each Brick module is driven in different semantic subspaces. Step S2: Hierarchical routing based on input The learnable query network takes the latent representation generated by the shared encoder as input and directly generates a global routing weight vector for the entire module set through softmax transformation. The routing decision does not depend on the forward output of any module. The global routing weight vector is normalized and projected onto a subset of locally available modules of the current heterogeneous AIoT device to obtain the local routing weight; The final prediction is obtained by weighting and aggregating the outputs of each module based on the local routing weights. Step S3: Task-Aware Decentralized Collaboration After each global training round, each heterogeneous AIoT device broadcasts the static signature vector of its Brick module to its neighboring heterogeneous AIoT devices; A joint score is calculated for each local module and each neighbor candidate module. The joint score is composed of a weighted sum of the signature cosine similarity and the module performance reliability score. The top K candidate modules that exceed the compatibility threshold are selected from the joint scores in descending order to form a module collaboration set; The local module parameters are updated by weighting and aggregating the local reliability weight with the reliability score of the module collaboration set. Synchronize the shared encoder parameters of various heterogeneous AIoT devices.

[0034] The above method achieves several advantages. First, specialized modules are constructed through module specialization bias, route-induced specialization learning, and partitioned static signature initialization. Second, input-driven hierarchical routing generates routing decisions from input features and decouples semantic module selection from execution constraints, thus achieving efficient and adaptive routing under heterogeneous deployment conditions. Finally, through reliability-aware module collaboration and selective aggregation, efficient module collaborative decision-making is achieved without central coordination, enabling decentralized collaborative training with module function differentiation, efficient routing, and low communication overhead on resource-constrained heterogeneous AIoT devices. Furthermore, the method achieves automatic module function differentiation, eliminates routing circular dependencies, and significantly reduces communication overhead under conditions without central coordination, resulting in a substantial improvement in the average accuracy and total training time for each device.

[0035] Below, we will refer to Figures 1 to 4 The steps of the method described above in this example embodiment will be explained in more detail.

[0036] In step S1, constraint-guided module construction is performed as follows: a learnable specialized bias vector is introduced for each Brick module, enabling each Brick module to generate a structured offset in the shared latent representation space, breaking the parameter symmetry; a partitioned static signature vector is calculated for each Brick module based on the category anchor representation; wherein, the static signature vector remains fixed throughout the training process and is only used for cross-heterogeneous AIoT device module matching; by jointly optimizing the module classification loss and the routing supervision loss, the sample assignment is determined by the routing allocation, driving each Brick module to achieve functional differentiation in different semantic subspaces.

[0037] Specifically, the constraint-guided module construction phase involves the joint design of three methods.

[0038] Module specialization bias: Introduce an independent and learnable specialization bias vector for each Brick module, superimpose module-specific structured biases on the shared latent representation, break the symmetric initialization state of multi-module parameters, and drive each module to differentiate in different semantic directions at an early stage.

[0039] Partitioned static signature initialization: Based on the mean latent representation of each category sample in the local data generated by the shared encoder, the category anchor representation vector is calculated; then, a partition mask is introduced to activate the relevant dimensions of the corresponding category, and after L2 normalization, the static signature vector of each module is obtained. This signature vector remains fixed throughout the training process and is used for semantic matching across device modules to avoid semantic drift during collaboration.

[0040] Route-induced specialization learning: The module classification loss and route supervision loss are combined into a local total loss, which drives the routing mechanism to allocate samples of different semantic categories to corresponding modules in a joint optimization manner, thereby realizing module functional partitioning under data-driven conditions. The three sub-mechanisms work together to form a closed loop of mutual constraints between structural bias, route allocation, and semantic anchors, ensuring stable functional differentiation of modules in a decentralized heterogeneous device environment.

[0041] In step S2, the hierarchical routing based on the input is as follows: the latent representation generated by the learnable query network with the shared encoder is used as input, and a global routing weight vector for the entire set of modules is directly generated through softmax transformation. The routing decision does not depend on the forward output of any module. The global routing weight vector is normalized and projected onto the subset of locally available modules of the current heterogeneous AIoT device to obtain the local routing weight. The final prediction is obtained by weighting and aggregating the outputs of each module based on the local routing weight.

[0042] Specifically, based on the hierarchical routing of the input, this stage decomposes module selection into two sub-steps: global route distribution generation and local availability constraint mapping.

[0043] Global route distribution generation: The learnable query network directly takes the latent representation output by the shared encoder as input, and outputs a route weight vector covering the entire module set after softmax transformation. Route decision-making does not require any module to perform forward computation, fundamentally eliminating the circular dependencies in the traditional MoE architecture. Since the query network and module parameters are jointly trained end-to-end, the routing strategy and module specialization can evolve co-evolved; at the same time, the route weights are dynamically generated based on sample input features, possessing the ability to adaptively adjust to different task data distributions.

[0044] Local availability constraint mapping: In a distributed heterogeneous deployment environment, each device holds only a subset of the global module set. The global routing weight retains only the component corresponding to the locally available modules, and then renormalizes it to obtain the local routing weight. The final prediction is obtained by weighted aggregation of the outputs of each local module according to the local routing weight. This mapping does not require information from other devices, ensuring cross-device consistency of routing semantics.

[0045] In step S3, task-aware decentralized collaboration is performed as follows: After each global training round, each heterogeneous AIoT device broadcasts the static signature vector of its Brick module to neighboring heterogeneous AIoT devices; a joint score is calculated for each local module and each neighboring candidate module, the joint score being a weighted sum of signature cosine similarity and module performance reliability score; the top K candidate modules exceeding the compatibility threshold are selected from high to low according to the joint score to form a module collaboration set; the local module parameters are updated by weighted aggregation of local reliability weight and the reliability score of the module collaboration set; and the shared encoder parameters of each heterogeneous AIoT device are synchronized.

[0046] Specifically, in the task-aware decentralized collaboration phase, selective collaboration at the module level is performed after local training in each global training round.

[0047] First, each device broadcasts the static signature vectors of all its modules to its neighboring devices. Second, for each local module, the joint score with each candidate module of its neighboring devices is calculated by weighted summation of the reliability score derived from the signature cosine similarity and the accuracy of the module validation set. Third, the top candidates with joint scores not lower than the compatibility threshold are selected. Each module is selected to form a collaborative set. Finally, the parameters are weighted and aggregated using the reliability weights of the local modules and the reliability weights of each candidate collaborative module to complete the module parameter update. The shared encoder is synchronized across all devices using an equal-weighted federated average method to maintain a consistent common representation space.

[0048] In one specific embodiment, the above and other technical features and advantages of this application will be described in detail below with reference to the accompanying drawings.

[0049] like Figure 2As shown, the deployment modes of this application and existing methods are compared as follows: Traditional monolithic model methods train dedicated neural networks independently for each task, resulting in models that cannot be reused across tasks and exhibiting poor flexibility in distributed scenarios; neural architecture search-based methods require training a supernetwork before searching for subnetworks, and the search process relies on centralized computing, resulting in huge overhead; the method proposed in this application is based on a modular architecture, where each device automatically constructs functionally differentiated Brick modules based on input data, and achieves cross-device module sharing through a decentralized collaboration mechanism, eliminating the need for central server coordination, supporting flexible deployment on heterogeneous devices, and significantly reducing communication overhead while maintaining high accuracy. Figure 3 As shown, the specific steps of this application are as follows: This application is directed to... An AIoT distributed system composed of heterogeneous AIoT devices, denoted as _____. Each device Holding local datasets And by the resource triplet Describe its resource characteristics, among which For equipment Local computing power (unit: FLOPS / s). For equipment The achievable communication rate (unit: bps). For equipment Storage capacity (in bytes). Module set deployed per device. ,common Each of the Brick modules is a module. Learning from the latent representation space To the task prediction space The mapping, where For the dimension of the potential representation, This represents the number of task categories.

[0050] The routing network generation module selects the weight vector:

[0051] in, For module The selection weight, express A probabilistic simplex of dimension 1, satisfying and The final prediction is obtained by weighted aggregation of the outputs of each module:

[0052] in, The potential representation generated by the shared encoder, For module The mapping function, For the predicted output in the task space. Each device In the global first Wheel completion time It consists of two parts: local computing time and communication time.

[0053] in, The number of local training rounds within each global round. The computation time for each local training round. This refers to the module communication time for each round. The computation time for each local training round is also included. Defined as:

[0054] in, For equipment The number of parameters involved in local training. The number of floating-point operations required for each parameter in one forward-backward propagation. For equipment Computing power. Module communication time. Defined as:

[0055] in, The actual number of module parameters (in bytes) transmitted in this round, and the communication rate. Based on Shannon's theorem:

[0056] in, For channel bandwidth, For communication power, For channel gain, This refers to noise power. Since all devices need to synchronize before proceeding to the next round, the global [number]th [unit / item]... Wheel completion time Determined by the slowest device ,all Total training time for each global training round for:

[0057] To jointly measure the trade-off between learning effectiveness and training efficiency, system efficiency is defined. for:

[0058] in, For equipment The accuracy of the validation set. The total time for all training rounds. These are normalized coefficients. System efficiency. This reflects both the model's prediction accuracy and training time cost. A higher value indicates a higher average accuracy rate achieved within the same time frame, meaning a higher overall system efficiency.

[0059] Based on the above definition of system efficiency, the optimization objective of this application is to maximize system efficiency under resource and performance constraints. :

[0060]

[0061]

[0062]

[0063] The constraints are defined as follows: Constraint C1 requires that the completion time of each device in each global round does not exceed the maximum allowable delay. To ensure the real-time performance of the system training process; constraint C2 requires that the sum of all module parameters deployed on each device does not exceed the device's storage capacity. ,in For module The number of parameters ensures the storage feasibility of module deployment; constraint C3 requires local training loss for each device. Not exceeding the preset upper limit This ensures a basic level of quality for local learning.

[0064] This application approaches the aforementioned optimization objective through the joint design of steps S1 to S3: the constraint-guided module construction mechanism in step S1 enables each module to learn complementary functional representations; the hierarchical routing mechanism in step S2 eliminates redundant computations and reduces local computation time; the selective module collaboration in step S3 only transmits task-related module parameters, reducing parameter transmission overhead, thereby improving overall system efficiency while satisfying the three constraints. .

[0065] Constraint-guided module construction (Step S1): The goal of the constraint-guided module construction phase is to enable each Brick module to automatically learn functionally complementary and semantically differentiated representations from the data. This phase is achieved through three methods: module specialization bias, partitioned static signature initialization, and route-induced specialization learning.

[0066] When multiple modules share the same encoder and use the same parameter initialization strategy, each module produces highly similar activation responses to the same input during the initial training phase. This leads to parameter symmetry degradation between modules, preventing them from naturally differentiating towards different semantic directions and losing the functional differentiation expected by modular design. To address this issue, module specialization bias introduces an independent learnable bias vector for each Brick module and superimposes it on the latent representation output by the shared encoder, forming a structured bias unique to each module in the shared representation space. Specifically, for each Brick module... ( Shared encoder Input sample Mapping to latent representation :

[0067] Module The middle representation Calculate using the following formula:

[0068] in, For module Unique transformation function, For module Independent, learnable, specialized bias vectors. Bias vectors for different modules. They are independent of each other and are trained end-to-end via backpropagation along with the network parameters. Finally, the intermediate representations are... The prediction head sent to this module Get Module Output prediction:

[0069] Module specialization bias generates structured initial differentiation in the shared representation space due to the independence of the bias vectors of each module, breaking the parameter symmetry state and encouraging each module to focus on feature learning of different semantic regions in the input space during subsequent training, thus providing a structural foundation for subsequent route-induced specialization.

[0070] In decentralized distributed AIoT scenarios, each device independently trains its local modules. Modules on different devices that perform similar semantic functions lack a unified alignment reference, making it difficult to effectively determine which modules are semantically related during cross-device collaboration. This leads to chaotic or ineffective selection of collaborative modules, thereby reducing the quality of knowledge fusion. Therefore, partitioned static signature initialization generates a fixed vector representation for each Brick module at the start of training, serving as the semantic anchor point for that module. This vector remains unchanged throughout the training and collaboration process and is specifically used for cross-device module semantic matching.

[0071] For local datasets Each category The mean of the output of all samples of this category after forward propagation through the shared encoder is calculated to obtain the category anchor representation vector. :

[0072] in, For category The sample set, Its sample size, This is the forward mapping function for the shared encoder. Secondly, it's for the module. Introducing partition mask vector Activate and assign to modules Category set The corresponding latent representation dimension is set, and the remaining dimensions are set to zero. Finally, the category anchor representation is multiplied element-wise by the partition mask, and then... Normalization yields the module static signature vector :

[0073] in, This indicates element-wise multiplication. express Normalization operation, For module The representative category of the assigned category. Static signature vector. After initialization, it remains fixed in all subsequent training rounds, does not change with updates to module or encoder parameters, and does not participate in forward routing calculation. It is only used for module similarity evaluation in the cross-device collaboration phase of step S3.

[0074] Each module's static signature vector carries semantic information corresponding to its assigned category. Modules on different devices that perform similar semantic functions have similar signature vectors, ensuring semantic alignment of modules across devices in a distributed environment. The signature remains fixed throughout the training process, avoiding semantic drift caused by dynamic updates of module parameters, and providing a stable and reliable reference basis for module identification in decentralized collaboration.

[0075] Furthermore, relying solely on the initial structural differentiation provided by the bias vector cannot guarantee that modules will stably focus on their respective semantic subspaces during continuous training. Without explicit routing supervision, modules may still tend to learn similar general features during training, resulting in insufficient functional differentiation. Therefore, route-induced specialization learning, through the joint optimization of module classification loss and routing supervision loss during training, uses the routing mechanism's sample allocation decision as a data partitioning method to guide different modules to focus on learning on their respective semantic subsets, thereby driving module functional differentiation from the data level.

[0076] Specifically, the overall objective function of local training It consists of two loss terms. The first term is the module classification loss. :

[0077] in, To be assigned to the module The set of categories, This is an indicator function (it takes the value 1 if the condition is true, and 0 otherwise). Assign the current input to the module for routing network. Routing weights This is the task loss function (such as cross-entropy loss). For module The mapping output of the latent representation, The true label of the sample. This loss term restricts each module to be responsible only for samples of the category within its semantic responsibility scope, and the loss contribution is weighted according to the routing weight.

[0078] The second item is the routing supervision loss. :

[0079] in, To query the network's output logits vector for the latent representation, True label for the sample The corresponding target module index (determined by the allocation relationship from category to module). The basic cross-entropy loss function is used. This loss term guides the routing network to learn the correct sample-to-module assignment relationship. The total local loss is obtained by weighted summation of the two losses:

[0080] in, These are weight coefficients used to control the strength of routing supervision. In each local training iteration, these coefficients are adjusted by... Perform backpropagation to jointly update module parameters, encoder parameters, and query network parameters.

[0081] Input-based hierarchical routing (step S2). The input-based hierarchical routing stage decomposes the module selection process into two parts: global route distribution generation and local availability constraint mapping. The former generates semantic route weights that cover all modules, while the latter adapts them to the actual available module subset of the current device.

[0082] Input-based global route distribution generation. In traditional MoE architectures, routers' selection weights for modules depend on the forward outputs of each module, creating a circular dependency of execution before selection. This forces all modules to participate in forward computation, failing to achieve true savings in conditional computation. Furthermore, the coupling between routing decisions and module outputs makes it difficult to guarantee routing consistency among distributed heterogeneous devices. Input-based global route distribution generation uses the latent representation of the input generated by a shared encoder as the sole condition. Through a learnable query network, it directly generates a route weight distribution covering all modules, without requiring any module to perform forward computation.

[0083] Specifically, design a learnable query network It receives the latent representation vector output by the shared encoder as its sole input, outputs a routing score vector for all modules, and then normalizes it using the softmax function to obtain the global routing weight vector. :

[0084] in, The Each component Representation module The weights selected under the current input satisfy the following conditions: and Searching the internet The module and encoder parameters are jointly trained end-to-end using the total local loss. Route decisions are generated based on the input-based global route distribution, relying solely on input features and completely decoupled from the forward computation of any module, eliminating circular dependencies in traditional MoE architectures. The forward computation of each module can be executed in full parallel, reducing inference latency. Route weights are dynamically generated from input features, possessing rapid adaptive adjustment capabilities to different task data distributions, demonstrating route-level flexibility.

[0085] Local routing mapping with availability constraints. In a decentralized distributed AIoT system, each device holds only a global set of modules. A subset If the weight components corresponding to modules not held are directly truncated, the weight normalization property is destroyed, leading to deviations in the prediction results. Therefore, it is necessary to smoothly map the global routing semantics to the locally available set of modules without accessing information from other devices. Thus, the global routing weight vector is projected onto the subset of modules actually available locally on the current device through local routing mapping with availability constraints. Re-normalization then adapts the semantically consistent global routing decisions to the heterogeneous deployment constraints of each device.

[0086] Assume the current device The subset of locally available modules is For each belonging to Module Its local routing weight Calculate using the following formula:

[0087] The global routing weights are renormalized on a subset of locally available modules to ensure that the sum of local routing weights is 1. The final prediction is obtained by weighted aggregation of the outputs of each local module according to its local routing weight. This mapping process is completed independently on the device itself, without needing to obtain module status or routing information from other devices. The global routing semantics are effectively adapted to the set of locally available modules on each device while ensuring normalization constraints, achieving a coordinated balance between routing consistency and execution feasibility under heterogeneous deployment conditions. Devices with different computing capabilities and module configurations can share a unified semantic routing framework, maintaining cross-device consistency of routing semantics while adapting to the actual resource constraints of each device.

[0088] Task-aware decentralized collaboration (step S3). The task-aware decentralized collaboration phase is executed after local training in each global training round. It achieves efficient knowledge sharing at the module level without central server coordination through static signature broadcasting, joint score calculation, selective collaboration set construction, and reliability weighted parameter aggregation.

[0089] After local training in each global training round, each device broadcasts the set of static signature vectors for all its local modules to neighboring devices for subsequent cross-device module similarity evaluation, without transmitting the original training data or complete module parameters. Each device only broadcasts the set of static signature vectors generated in step S1. Neighboring devices receive the signature vectors and cache them for joint score calculation in this round. The joint score is an evaluation metric that comprehensively measures the semantic relevance between neighboring candidate modules and local modules, as well as the reliability of model performance, and is used to select the most valuable collaborators from the neighboring candidate module pool. For local devices... The module on Neighbor candidate modules Joint rating Calculate using the following formula:

[0090] in, For local modules static signature vector With candidate modules static signature vector Cosine similarity between them:

[0091] Candidate module Reliability rating:

[0092] in, Candidate module Classification accuracy on its local validation set; This is the balance coefficient between the similarity component and the reliability component.

[0093] For constructing the module collaboration set, a dual screening process is performed on neighbor candidate modules based on joint scoring. First, semantically irrelevant candidate modules are filtered out by a compatibility threshold, and then top-ranked modules are selected. Select the highest combined score These candidate modules constitute the collaborative source set for this round of parameter aggregation. (For local modules...) The construction of the collaborative set consists of two steps. The first step is to select collaborations with a joint score no lower than a preset compatibility threshold. The candidate modules constitute the candidate set. :

[0094] in, For equipment The set of all neighbor candidate modules, This is a preset compatibility threshold. The second step is to select from the candidate set... China selects the top scorers from highest to lowest based on their joint scores. The candidate modules constitute the module collaboration set. Then, calculate the local device. Reliability weight ,in For local devices The accuracy of the validation set is then calculated. Subsequently, the corresponding module parameters are obtained from the devices where each candidate module in the collaboration set is located, and the module parameters are updated by weighted averaging, using the performance and reliability of the local module and each collaborative candidate module as weights.

[0095]

[0096] in, Candidate modules for collaboration The parameters, Candidate module The reliability score is calculated, with the denominator being the sum of all weights, and is used for normalization to ensure the numerical stability of the aggregation parameters.

[0097] Figure 4 The paper demonstrates a comparison of the system efficiency of the proposed method with existing methods under varying transmission rates on different datasets. Figure 4 As shown, BrickNN consistently outperforms all baseline methods across all transmission rates on the four datasets. Averaging across all transmission rates and datasets, BrickNN achieves average system efficiency improvements of 100.25%, 12.45%, 497.27%, and 10.38% compared to Monolithic D-SGD, GossipFL, D-FedEM, and BrickNN-Random, respectively. On the CIFAR-10 dataset, the average system efficiency of this application reaches 14.32, representing improvements of 86.68%, 8.88%, 462.80%, and 2.18% compared to the monolithic model distributed stochastic gradient descent method, GossipFL method, D-FedEM method, and stochastic cooperative variant, respectively. These results demonstrate that this application, through a joint design of modular functional differentiation, input-driven routing, and selective decentralized cooperation, strikes a balance between accuracy and communication efficiency, consistently exhibiting a comprehensive advantage in system efficiency.

[0098] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that these steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps. Furthermore, it is readily understood that these steps may be executed synchronously or asynchronously, for example, in multiple modules / processes / threads.

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

Claims

1. A method for constructing a self-organizing modular neural network for intelligent Internet of Things (IoT) environments, characterized in that, include: Step S1: Constraint-guided module construction A learnable specialized bias vector is introduced for each Brick module, enabling each Brick module to generate a structured bias in a shared latent representation space, thus breaking the parameter symmetry. For each Brick module, a partitioned static signature vector is calculated based on the category anchor representation; the static signature vector remains fixed throughout the training process and is only used for cross-heterogeneous AIoT device module matching. By jointly optimizing the module classification loss and the route supervision loss, and using the route assignment to determine the sample attribution, the functional differentiation of each Brick module is driven in different semantic subspaces. Step S2: Hierarchical routing based on input The learnable query network takes the latent representation generated by the shared encoder as input and directly generates a global routing weight vector for the entire module set through softmax transformation. The routing decision does not depend on the forward output of any module. The global routing weight vector is normalized and projected onto a subset of locally available modules of the current heterogeneous AIoT device to obtain the local routing weight; The final prediction is obtained by weighting and aggregating the outputs of each module based on the local routing weights. Step S3: Task-Aware Decentralized Collaboration After each global training round, each heterogeneous AIoT device broadcasts the static signature vector of its Brick module to its neighboring heterogeneous AIoT devices; A joint score is calculated for each local module and each neighbor candidate module. The joint score is composed of a weighted sum of the signature cosine similarity and the module performance reliability score. The top K candidate modules that exceed the compatibility threshold are selected from the joint scores in descending order to form a module collaboration set; The local module parameters are updated by weighting and aggregating the local reliability weight with the reliability scores of each module in the module collaboration set. Synchronize the shared encoder parameters of various heterogeneous AIoT devices.

2. The method for constructing a self-organizing modular neural network for an intelligent Internet of Things environment according to claim 1, characterized in that, Self-organizing modular neural networks for smart IoT environments A distributed AIoT system consisting of heterogeneous AIoT devices, denoted as ______. ; Each heterogeneous AIoT device Holding local datasets And by the resource triplet Describe its resource characteristics; among which, For heterogeneous AIoT devices Local computing power For heterogeneous AIoT devices The achievable communication rate, For heterogeneous AIoT devices Storage capacity; Each heterogeneous AIoT device deploys a set of modules. ,common Each of the Brick modules is a module. Learning from the latent representation space To the task prediction space The mapping; where, For the dimension of the potential representation, This represents the number of task categories.

3. The method for constructing a self-organizing modular neural network for an intelligent Internet of Things environment according to claim 2, characterized in that, Step S1 specifically includes: For each Brick module Introducing independent, learnable specialized bias vectors Overlay it onto the shared encoder Latent representation of the output After being processed by a transformation function, the Brick module is obtained. The middle representation ; intermediate representation Send to Brick module Predicting head The obtained output prediction : Based on local dataset Samples of each category The mean of the output of all samples of this category after forward propagation through the shared encoder is calculated to obtain the category anchor representation vector. ; For each Brick module Introducing partition mask vector Activate and assign to the Brick module Category set The corresponding latent representation dimension is used, and the remaining dimensions are set to zero. Representing category anchors After element-wise multiplication with the partition mask, Normalization yields the Brick module. static signature vector ; Construct a classification loss that includes modules and routing supervision loss joint loss function ; By analyzing the joint loss function Perform reverse propagation to jointly update module parameters, encoder parameters, and routing network parameters.

4. The method for constructing a self-organizing modular neural network for an intelligent Internet of Things environment according to claim 3, characterized in that, Shared encoder Input sample Mapping to latent representation : Intermediate representation for: in, For transformation function, For independent, learnable, specialized bias vectors; Output prediction for: Category anchor representation vector for: in, For category The sample set, Its sample size, Forward mapping function of shared encoder; Brick module static signature vector for: in, This indicates element-wise multiplication. express Normalization operation, For Brick module The representative category of the assigned category; Module classification loss for: in, Indicates in the device Local dataset Above all samples Seeking expectations, For Brick module The representative category of the assigned category, For indicator functions, The routing weight assigned to module m by the current input in the routing network. For the task loss function, For Brick module The mapping output of the latent representation, The true labels for the samples; Route supervision loss for: in, To query the network's output logits vector for the latent representation, This is the index of the target module corresponding to the true label y of the sample. The cross-entropy loss function is based on this. Joint loss function for: in, Weighting coefficients are used to control the strength of route supervision.

5. The method for constructing a self-organizing modular neural network for an intelligent Internet of Things environment according to claim 4, characterized in that, Step S2 specifically includes: Through a learnable query network The latent representation of the shared encoder output The data is mapped to a route score vector, then normalized using the softmax function to generate a global route weight vector that satisfies the probabilistic simplex constraint. ; For heterogeneous AIoT devices Locally available module subset , global route weight vector Components in In this subset Renormalization is performed on the top to obtain the local route weight. ; The final prediction is obtained by weighting and aggregating the outputs of each module based on the local routing weights.

6. The method for constructing a self-organizing modular neural network for an intelligent Internet of Things environment according to claim 5, characterized in that, Global route weight vector for: in, The Each component Brick module The weights selected under the current input satisfy the following conditions: and ; Local route weight for: in, The module index for summation traversal.

7. The method for constructing a self-organizing modular neural network for an intelligent Internet of Things environment according to claim 6, characterized in that, Step S3 specifically includes: For local heterogeneous AIoT devices Brick module on Neighbor candidate modules Calculate the joint score ; Based on joint scoring First, filter out those with scores no lower than the compatibility threshold. The candidate modules constitute the candidate set. ; From the candidate set Select the one with the highest joint score The candidate modules constitute the module collaboration set. ; heterogeneous AIoT devices Reliability weight Collaboration with modules Reliability scores of each candidate module The parameters of the local module and the collaborative module are weighted and averaged to update the module parameters.

8. The method for constructing a self-organizing modular neural network for an intelligent Internet of Things environment according to claim 7, characterized in that, Joint rating for: in, For Brick module static signature vector With candidate modules static signature vector Cosine similarity between them: ; Candidate modules Reliability rating: , Candidate modules Classification accuracy on its local validation set; This is a balance coefficient between the similarity component and the reliability component; The module parameter update process is as follows: in, Candidate modules The parameters.

Images