An emergency resource recommendation method, device, equipment, medium and product

Abstract

The present disclosure relates to an emergency resource recommendation method, device, equipment, medium and product, the method comprising: obtaining task data; the task data comprising target enterprise data, candidate emergency resource data and target emergency scene data; mapping the task data into a heterogeneous graph model, and determining target nodes corresponding to the task data; determining pseudo labels based on the similarity between new nodes in the target nodes and historical nodes in the heterogeneous graph model, and performing feature aggregation on the target nodes based on the pseudo labels to obtain feature representations of the target nodes; calculating recommendation scores corresponding to each candidate emergency resource based on the feature representations and the pseudo labels, and screening and sorting the candidate emergency resources based on the recommendation scores to obtain a target recommendation result. The present disclosure can improve the accuracy, rationality and timeliness of emergency resource recommendation, and improve the efficiency of emergency resource allocation and emergency response capability.

Description

Technical Field

[0001] This disclosure relates to the field of emergency management technology, and in particular to an emergency resource recommendation method, apparatus, equipment, medium, and product. Background Technology

[0002] In the process of safety production and emergency management in coal-fired power plants, the rational recommendation of emergency resources is of great significance. Since the emergency response process of coal-fired power plants is complex and resource scheduling involves many factors, there is an urgent need to provide a resource recommendation method suitable for emergency scenarios in order to achieve efficient allocation and rapid response of emergency resources.

[0003] In related technologies, resource scheduling and recommendation schemes based on rule matching or traditional recommendation models are usually adopted. However, such schemes are not adaptable to actual emergency needs, resulting in poor accuracy and timeliness of recommendation results, making it difficult to meet the actual application needs of emergency resource recommendation for coal-fired power plants. Summary of the Invention

[0004] This disclosure provides an emergency resource recommendation method, apparatus, equipment, medium, and product.

[0005] According to a first aspect of this disclosure, an emergency resource recommendation method is provided, the method comprising: Acquire task data; the task data includes target enterprise data, candidate emergency resource data, and target emergency scenario data; The task data is mapped to a heterogeneous graph model to determine the target node corresponding to the task data; Pseudo-labels are determined based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, and feature aggregation is performed on the target nodes based on the pseudo-labels to obtain the feature representation of each target node. Based on the feature representation and the pseudo-label, a recommendation score is calculated for each candidate emergency resource. The candidate emergency resources are then filtered and sorted based on the recommendation score to obtain the target recommendation result.

[0006] Further, mapping the task data to a heterogeneous graph model and determining the target node corresponding to the task data includes: The target enterprise data is encoded using feature vectorization to obtain enterprise nodes; The candidate emergency resource data is encoded using feature vectorization to obtain resource nodes; The target emergency scenario data is encoded using feature vectorization to obtain scenario nodes; The enterprise node, the resource node, and the scene node are mapped to the heterogeneous graph model to obtain the target node.

[0007] Further, the step of determining pseudo-labels based on the similarity between newly added nodes in the target node and historical nodes in the heterogeneous graph model includes: The newly added nodes are subjected to feature encoding and normalization to obtain the attribute embedding vector corresponding to the newly added nodes; wherein, the newly added nodes include at least one of newly added enterprise nodes, newly added resource nodes, and newly added scene nodes; Obtain the embedding representation of each of the historical nodes, and calculate the similarity between the attribute embedding vector and each of the embedding representations to obtain the similarity calculation result between the new node and each of the historical nodes; The pseudo-label is determined based on the similarity calculation results.

[0008] Further, determining the pseudo-label based on the similarity calculation result includes: Based on the similarity calculation results, a preset number of historical nodes with the highest similarity to the newly added node are selected from the historical nodes to obtain the target historical node; Based on the historical scheduling information and resource scenario matching information of the target historical node, a pseudo-label determination rule is constructed. The pseudo-label is determined based on the pseudo-label determination rule.

[0009] Further, the step of aggregating features of the target nodes based on the pseudo-labels to obtain feature representations of each target node includes: Based on the pseudo-tag, a virtual association is established between the newly added node and the target historical node; wherein, the virtual association is used to characterize the virtual interaction relationship between the newly added node and the target historical node; The target node is input into a dual-path graph attention network, and the heterogeneous graph model is subjected to feature extraction through a multi-head attention mechanism to obtain the feature extraction result corresponding to the target node. The feature extraction results are subjected to cross-type feature aggregation to obtain the feature representation.

[0010] Further, the step of calculating the recommendation score corresponding to each of the candidate emergency resources based on the feature representation and the pseudo-label includes: Based on the feature representations of each target node, extract the enterprise representation corresponding to the enterprise node, the resource representation corresponding to the resource node, and the scene representation corresponding to the scene node; The enterprise representation, resource representation, scene representation, and pseudo-label are fused to obtain fused features; wherein, the feature fusion includes introducing a Hadamard product interaction term; The fused features are input into a multilayer perceptron for mapping to obtain the recommendation score.

[0011] Furthermore, the step of filtering and ranking the candidate emergency resources based on the recommendation score to obtain the target recommendation result includes: Based on the upper limit of response time, the upper limit of transportation distance, and inventory constraints, the candidate emergency resources are filtered to obtain the target candidate resources; Based on the recommendation score, transportation cost, and resource scarcity weight, the target candidate resources are sorted to obtain a target resource list; The list of target resources is determined as the target recommendation result.

[0012] Furthermore, before mapping the task data to a heterogeneous graph model and determining the target node corresponding to the task data, the method further includes: Acquire multi-source data, including enterprise data, emergency resource data, and emergency scenario data; Based on the multi-source data, construct enterprise node sets, resource node sets, and scenario node sets; Based on the relationships between the enterprise node set, the resource node set, and the scene node set, a heterogeneous edge set is constructed. The heterogeneous graph model is established based on the enterprise node set, the resource node set, the scene node set, and the heterogeneous edge set.

[0013] According to a second aspect of this disclosure, an emergency resource recommendation device is provided, the device comprising: The first acquisition module is used to acquire task data; the task data includes target enterprise data, candidate emergency resource data, and target emergency scenario data. The determination module is used to map the task data to a heterogeneous graph model and determine the target node corresponding to the task data; An aggregation module is used to determine pseudo-labels based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, and to perform feature aggregation on the target nodes based on the pseudo-labels to obtain feature representations of each target node. The recommendation module is used to calculate the recommendation score corresponding to each candidate emergency resource based on the feature representation and the pseudo-label, and to filter and sort the candidate emergency resources based on the recommendation score to obtain the target recommendation result.

[0014] According to a third aspect of this disclosure, an electronic device is provided. The electronic device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described above.

[0015] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the methods described above.

[0016] According to a fifth aspect of this disclosure, a computer program product is provided. The computer program product includes a computer program that, when executed by a processor, implements the methods described above in this disclosure.

[0017] This disclosure provides an emergency resource recommendation method, apparatus, device, medium, and product. First, task data is acquired, including target enterprise data, candidate emergency resource data, and target emergency scenario data. Then, the task data is mapped to a heterogeneous graph model to determine the target nodes corresponding to the task data. Next, pseudo-labels are determined based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model. Features of the target nodes are then aggregated based on the pseudo-labels to obtain feature representations for each target node. Finally, recommendation scores are calculated for each candidate emergency resource based on the feature representations and pseudo-labels. The candidate emergency resources are then filtered and ranked based on the recommendation scores to obtain the target recommendation results.

[0018] As described above, this embodiment of the present disclosure maps target enterprise data, candidate emergency resource data, and target emergency scenario data into a heterogeneous graph model to determine target nodes corresponding to task data, thereby achieving a unified representation of enterprises, resources, and scenarios. Based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, pseudo-labels are determined, and feature aggregation is performed on the target nodes based on these pseudo-labels. This alleviates the problem of missing features caused by the lack of historical interaction data for newly added enterprise nodes, resource nodes, or scenario nodes, and improves the completeness of the target node feature representation. Based on the feature representation and pseudo-labels, recommendation scores are calculated for each candidate emergency resource, and candidate emergency resources are screened and ranked based on these recommendation scores. This achieves an effective evaluation of the matching relationship between candidate emergency resources and target enterprises and target emergency scenarios, thereby improving the accuracy, rationality, and timeliness of emergency resource recommendation results, and ultimately improving the efficiency of emergency resource allocation and emergency response capabilities. Attached Figure Description

[0019] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0020] Figure 1A flowchart illustrating an exemplary embodiment of this disclosure of an emergency resource recommendation method; Figure 2 One of the flowcharts for an emergency resource recommendation method provided as another exemplary embodiment of this disclosure; Figure 3 A second flowchart of an emergency resource recommendation method provided for another exemplary embodiment of this disclosure; Figure 4 Flowchart 3 of an emergency resource recommendation method provided for another exemplary embodiment of this disclosure; Figure 5 Flowchart four of an emergency resource recommendation method provided for another exemplary embodiment of this disclosure; Figure 6 Fifth flowchart of an emergency resource recommendation method provided for another exemplary embodiment of this disclosure; Figure 7 A general technical framework diagram of an emergency resource recommendation system provided for an exemplary embodiment of this disclosure; Figure 8 A schematic diagram showing the comparison of experimental results provided for an exemplary embodiment of this disclosure; Figure 9 A schematic block diagram of the functional modules of an emergency resource recommendation device provided in an exemplary embodiment of this disclosure; Figure 10 A structural block diagram of an electronic device provided as an exemplary embodiment of this disclosure; Figure 11 A structural block diagram of a computer system provided as an exemplary embodiment of this disclosure; Figure 12 A structural block diagram of a computer program product provided for an exemplary embodiment of this disclosure. Detailed Implementation

[0021] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0022] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0023] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0024] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more". The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0025] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0026] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0027] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device. It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation of this disclosure; other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0028] Emergency resource recommendation in coal-fired power plants is a complex decision-making problem driven by multi-entity collaboration and multi-source heterogeneous data. It involves not only the acquisition of enterprise data, emergency resource data, and emergency scenario data, but also the modeling of heterogeneous relationships, node feature representation, cold start node processing, and the generation of resource recommendation results. In existing technologies, the characterization of the relationship between enterprises, resources, and scenarios generally relies on rule matching, experience judgment, or simple recommendation models, lacking a unified model for the complex relationship structure between multiple types of entities. This can easily lead to insufficient utilization of relationship information or the absence of key relationships. At the same time, in cold start scenarios such as adding new enterprises, new resources, or new scenarios, due to the lack of historical interaction data for relevant nodes, existing solutions often fail to form effective node representations, which can easily lead to biased recommendation results and affect the accuracy and stability of resource matching. In addition, although some recommendation methods can achieve resource screening under static conditions, they still suffer from insufficient feature expression capabilities, weak dynamic adaptability, and low timeliness of recommendation results when facing situations such as rapid scenario changes, numerous constraints, and high timeliness requirements for resource scheduling in emergency tasks. Therefore, it is necessary to provide an emergency resource recommendation scheme that can take into account heterogeneous relationship modeling, cold start node compensation, and resource recommendation decision-making capabilities.

[0029] In one embodiment, such as Figure 1 As shown, an emergency resource recommendation method is provided, including the following steps: Step 101: Obtain task data.

[0030] Here, the executing entity can obtain task data, which includes target enterprise data, candidate emergency resource data, and target emergency scenario data. Target enterprise data can be used to represent the enterprise entity information involved in the current emergency task; candidate emergency resource data can be used to represent the resource information currently available for recommendation and allocation; and target emergency scenario data can be used to represent the emergency scenario information currently awaiting handling. It should be understood that task data can originate from enterprise business systems, resource ledgers, scheduling logs, monitoring and alarm systems, event reports, or other relevant data sources, without restriction.

[0031] In one possible embodiment, the target enterprise data may include data corresponding to key entities such as coal mines, power plants, and dispatch centers. Coal mines can correspond to the resource supply side, power plants to the resource demand side, and dispatch centers to the coordination and control side. Candidate emergency resource data may include data corresponding to resources such as emergency coal, core spare parts, emergency repair technicians, and special vehicles. Target emergency scenario data may include data corresponding to typical emergency scenarios such as unplanned equipment outages, fuel supply interruptions, natural disasters, and production safety accidents. By acquiring the above task data, enterprise, resource, and scenario inputs directly related to the current emergency task can be formed, providing a data foundation for subsequently determining the corresponding nodes in the heterogeneous graph model.

[0032] Specifically, after obtaining the task data, the executing entity can distinguish the task data according to the data type to differentiate between target enterprise data, candidate emergency resource data, and target emergency scenario data. Since coal-fired power emergency scenarios usually involve enterprise entities, multiple types of resources, and dynamically evolving scenario requirements, the task data obtained in this step actually constitutes the input object for subsequent unified heterogeneous modeling. This enables subsequent node construction, graph structure mapping, and recommendation decisions to be carried out around the three types of entities: "enterprise-resource-scenario". It should be understood that the task data can be either structured data or pre-processed unstructured data, without any restrictions here.

[0033] Step 102: Map the task data to the heterogeneous graph model and determine the target node corresponding to the task data.

[0034] Here, after acquiring the task data, the executing entity can map the task data to a heterogeneous graph model to determine the target nodes corresponding to the task data. The heterogeneous graph model can be a pre-built "enterprise-resource-scenario" heterogeneous graph model, used to represent the multi-dimensional relationships between enterprise entities, schedulable resources, and emergency scenarios within a unified topological space. Target nodes can include enterprise nodes corresponding to the target enterprise data, resource nodes corresponding to the candidate emergency resource data, and scenario nodes corresponding to the target emergency scenario data. In other words, the purpose of this step is to uniformly convert the enterprise, resource, and scenario data in the current task into node representations in a graph structure, so that subsequent pseudo-label generation, feature propagation, and resource recommendation can be performed by combining historical nodes, heterogeneous relationship edges, and graph neural networks in the graph.

[0035] In one possible embodiment, mapping task data to a heterogeneous graph model and determining the target node corresponding to the task data includes the following steps: The target enterprise data is encoded using feature vectorization to obtain enterprise nodes; The candidate emergency resource data is encoded using feature vectorization to obtain resource nodes; The target emergency scenario data is encoded using feature vectorization to obtain scenario nodes; Enterprise nodes, resource nodes, and scenario nodes are mapped to a heterogeneous graph model to obtain the target node.

[0036] Specifically, after obtaining the task data, the executing entity can first perform feature vectorization encoding on the target enterprise data to obtain enterprise nodes. Enterprise nodes can belong to a set of enterprise nodes. Enterprise node set It can cover key entities such as coal mines, power plants, and dispatch centers. The attribute vectors of enterprise nodes can include, but are not limited to, information such as real-time production load, resource reserve thresholds, geospatial coordinates, and emergency response levels. By encoding the above attributes, enterprise nodes can represent the supply capacity, demand characteristics, location conditions, and emergency response capabilities of the enterprise entity in the current task.

[0037] In one possible embodiment, the executing entity may further perform feature vectorization encoding on the candidate emergency resource data to obtain resource nodes, which may belong to a resource node set. resource node set This can encompass resource entities such as emergency coal, core spare parts, emergency repair technicians, and special vehicles. The attribute vectors of resource nodes can include information such as resource specifications, dynamic inventory status, pre-call time, and spatial distribution, without any restrictions. By encoding candidate emergency resource data as described above, resource nodes can characterize the resource type, availability, allocation timeliness, and spatial reachability of candidate emergency resources.

[0038] In one possible embodiment, the executing entity may further perform feature vectorization encoding on the target emergency scenario data to obtain scenario nodes, which may belong to a scenario node set. Scene node set It can cover typical emergency scenarios such as unplanned equipment outages, fuel supply disruptions, natural disasters, and production safety accidents. The attribute vectors of scenario nodes can include information such as scenario semantic labels, the degree of urgency, the spatiotemporal impact range, and the probability of evolution, without any restrictions. By encoding the target emergency scenario data as described above, scenario nodes can represent the type characteristics, urgency, and possible evolution trends of the scenario corresponding to the current task.

[0039] In one possible embodiment, after obtaining the enterprise node, resource node, and scenario node, the executing entity can map the enterprise node, resource node, and scenario node to a heterogeneous graph model to obtain the target node. Here, in addition to nodes, the heterogeneous graph model may also include heterogeneous edges constructed based on business collaboration logic to represent the association relationships between different types of nodes. For example, the heterogeneous graph model may include supply-demand association edges to represent the affiliation or service relationship between the enterprise entity and schedulable resources. This can include resource-scenario adaptation edges (SPEs) used to characterize the utility of a specific resource in a specific emergency scenario. It can also include enterprise-enterprise collaboration edges (E- ... By mapping enterprise nodes, resource nodes, and scene nodes to this heterogeneous graph model, target nodes corresponding to the current task data can be determined within a unified topology space, providing a graph structure foundation for subsequent node identification, pseudo-label generation, feature aggregation, and recommendation scoring.

[0040] Specifically, after mapping enterprise nodes, resource nodes, and scene nodes to the heterogeneous graph model, if the executing entity finds that a certain enterprise node, resource node, or scene node lacks a corresponding historical interaction record in the heterogeneous graph model, it can identify the node as a new node. In subsequent steps, pseudo-labels are generated based on the similarity between the new node and historical nodes in the heterogeneous graph model. These pseudo-labels are then used to perform feature propagation and representation updates on the node. In other words, this step not only completes the mapping of task data to graph nodes but also lays the groundwork for subsequent cold-start node identification and pseudo-label-driven feature enhancement.

[0041] In one possible embodiment, during the process of acquiring and mapping task data, the executing entity can also introduce an incremental sensing mechanism. When it captures the node status during coal-fired power production, such as dynamic inventory, real-time production load, and environmental characteristics, such as the instantaneous drift of the disaster evolution range, the executing entity does not need to rebuild the entire heterogeneous graph model. Instead, it quickly triggers incremental updates of the corresponding node attributes and related edge weights. Through this dynamic update mechanism, it can be ensured that the recommended strategy always aligns with the optimal state at the current moment, significantly reducing the risk of delays in emergency response.

[0042] Step 103: Determine pseudo-labels based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, and perform feature aggregation on the target nodes based on the pseudo-labels to obtain the feature representation of each target node.

[0043] Here, after identifying the target nodes corresponding to the task data, the executing entity can determine pseudo-labels based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model. Based on these pseudo-labels, feature aggregation is performed on the target nodes to obtain feature representations for each target node. Newly added nodes can include at least one of newly added enterprise nodes, newly added resource nodes, and newly added scenario nodes. Historical nodes can be nodes that already exist in the heterogeneous graph model and have historical scheduling records, resource call trajectories, or interaction behavior data. It should be understood that "cold start" here can refer to a situation where some nodes in the target nodes are difficult to accurately represent directly based on historical behavior information due to new system access, first-time participation in the recommendation process, or lack of effective historical interaction data. Accordingly, newly added nodes can be considered nodes with cold start problems.

[0044] In other words, the purpose of this step is to identify cold start nodes in the current task's corresponding nodes, and to construct high-confidence pseudo-labels for new nodes by using the structural embedding information and historical scheduling information of historical nodes. Furthermore, the pseudo-labels are introduced into the heterogeneous graph learning process to make up for the feature loss problem caused by the lack of historical interaction data for new nodes, thereby obtaining a more complete and stable node feature representation.

[0045] In one possible embodiment, such as Figure 2 As shown, the pseudo-labels are determined based on the similarity between newly added nodes in the target node and historical nodes in the heterogeneous graph model, including the following steps: Step 201: Perform feature encoding and normalization on the newly added nodes to obtain the attribute embedding vector corresponding to the newly added nodes.

[0046] Here, after determining the target node corresponding to the task data, the executing entity can perform feature encoding and normalization on the newly added node to obtain the attribute embedding vector corresponding to the newly added node. The newly added node includes at least one of the following: a newly added enterprise node, a newly added resource node, and a newly added scenario node. The attribute embedding vector is used to characterize the initial features of the newly added node in the attribute semantic space. For example, for a newly added enterprise node, the attribute embedding vector can characterize the enterprise's production capacity, resource reserve capacity, geographical location, and emergency response capability; for a newly added resource node, the attribute embedding vector can characterize the resource type, resource specifications, dynamic inventory status, and call lead time; for a newly added scenario node, the attribute embedding vector can characterize information such as scenario semantic label, degree of urgency, spatiotemporal impact range, and evolution trend.

[0047] In one possible embodiment, the executing entity can encode the original attributes of the newly added node and normalize the encoding result to eliminate the dimensional differences between different attribute dimensions, thereby obtaining the attribute embedding vector corresponding to the newly added node. It should be understood that the encoding method can include linear mapping, nonlinear mapping, or other methods that can transform the original attribute features into vector representations, and is not limited thereto.

[0048] Step 202: Obtain the embedding representation of each historical node, and calculate the similarity between the attribute embedding vector and each embedding representation to obtain the similarity calculation result between the new node and each historical node.

[0049] Here, after obtaining the attribute embedding vector corresponding to the new node, the executing entity can obtain the embedding representation of each historical node and calculate the similarity between the attribute embedding vector and each embedding representation to obtain the similarity calculation result between the new node and each historical node. Here, a historical node can be understood as a node that already exists in the heterogeneous graph model and has historical scheduling records, historical interaction data or historical embedding representations. Historical nodes can include historical enterprise nodes, historical resource nodes and historical scene nodes, without any restrictions. The embedding representation of the historical node is used to characterize the comprehensive features of the corresponding historical node in the heterogeneous graph topology and semantic space.

[0050] In one possible embodiment, the executing entity can use cosine similarity to measure the similarity between new nodes and historical nodes. Accordingly, the similarity between new nodes and historical nodes can be expressed as:

[0051] in, This represents the attribute embedding vector corresponding to the newly added node u. This represents the embedding representation corresponding to the historical node v. This represents the similarity between the newly added node u and the historical node v. By using the above method, we can obtain the similarity calculation results between the newly added node and each historical node, which can serve as the basis for subsequent selection of target historical nodes and construction of pseudo-label judgment rules.

[0052] Specifically, after obtaining the similarity calculation results between the new node and each historical node, the executing entity can sort the historical nodes according to the similarity size to select historical nodes that are closer to the semantic and structural features of the new node. Since these historical nodes usually have stronger reference value, they can be further used as the basis for subsequent pseudo-label generation and feature propagation.

[0053] Step 203: Determine pseudo-labels based on similarity calculation results.

[0054] Here, after obtaining the similarity calculation results between the new node and each historical node, the executing entity can determine pseudo-labels based on the similarity calculation results. Pseudo-labels can be understood as auxiliary labels constructed based on the similarity relationship between the new node and historical nodes and historical business information when there are insufficient real labels or missing historical interaction data. They are used to characterize the potential attributes of the new node in terms of resource matching, scenario adaptation or scheduling priority.

[0055] In one possible embodiment, determining pseudo-labels based on similarity calculation results includes the following steps: Based on the similarity calculation results, a preset number of historical nodes with the highest similarity to the newly added node are selected from the historical nodes to obtain the target historical node; Based on the historical scheduling information and resource scenario matching information of the target historical nodes, a pseudo-label determination rule is constructed. Identify fake labels based on fake label identification rules.

[0056] Specifically, after obtaining the similarity calculation results between the new node and each historical node, the executing entity can select a preset number of high-confidence neighbor entities with the highest similarity to the new node from historical successful scheduling cases as target historical nodes. Here, the preset number can be set according to business needs, for example, taking the top K historical nodes with the highest similarity. Subsequently, the executing entity can comprehensively consider the historical scheduling frequency, success rate, and resource-scenario matching effect of the target historical nodes to construct pseudo-label judgment rules. When the historical successful call frequency of a resource in a specific emergency scenario exceeds a set threshold, or the resource-scenario embedding similarity exceeds a preset threshold, a corresponding resource-scenario matching pseudo-label can be generated to indicate that the resource has high adaptability potential in that scenario. It should be understood that the pseudo-labels generated in the above manner are derived from the joint constraints of real business data and the embedding space structure, and therefore have high credibility and interpretability.

[0057] Specifically, after obtaining the similarity calculation results between the newly added node and each historical node, the executing entity can further perform feature aggregation on the target node based on the determined pseudo-labels to obtain the feature representation of each target node. In other words, step 103 does not only stop at the generation of pseudo-labels, but further introduces pseudo-labels into the heterogeneous graph learning process to assist cold-start nodes in participating in the feature propagation and representation update of the graph neural network.

[0058] In this embodiment, firstly, the executing entity performs feature encoding and normalization on the newly added node to obtain the attribute embedding vector corresponding to the newly added node; then, the executing entity obtains the embedding representation of each historical node and calculates the similarity between the attribute embedding vector and each embedding representation to obtain the similarity calculation result between the newly added node and each historical node; finally, the executing entity determines the pseudo-label based on the similarity calculation result.

[0059] As described above, this embodiment obtains the attribute embedding vector corresponding to the new node by performing feature encoding and normalization on the new node, and further obtains the embedding representation of each historical node, calculates the similarity between the new node and each historical node, and can identify reference nodes with high relevance to the new node from the historical nodes. Based on this, pseudo-labels are determined based on the similarity calculation results. This can provide effective auxiliary representation information for new nodes when there is a lack of historical interaction data for new enterprise nodes, new resource nodes, or new scene nodes, thereby alleviating the cold start problem, improving the accuracy and completeness of subsequent node feature aggregation results, and providing support for achieving more accurate emergency resource recommendations.

[0060] In one possible embodiment, such as Figure 3 As shown, feature aggregation of target nodes based on pseudo-labels is performed to obtain the feature representation of each target node, including the following steps: Step 301: Based on pseudo-labels, establish a virtual association between the newly added node and the target historical node.

[0061] Here, after identifying the pseudo-labels, the executing entity can establish virtual associations between the new node and the target historical node based on these pseudo-labels. These virtual associations represent the virtual interaction relationships between the new node and the target historical node. In other words, when a new node lacks real historical interaction edges, the executing entity can utilize the potential associations reflected by the pseudo-labels to supplement the virtual connection between the new node and the target historical node. This allows the new node to obtain a path for information transmission with historical nodes in the heterogeneous graph model. In this way, the problem of insufficient structural information caused by the lack of historical edges in new nodes can be alleviated while maintaining the semantic consistency of the graph structure. It should be understood that these virtual associations do not necessarily indicate that real business interactions have occurred between the new node and the target historical node, but rather represent the graph structure connections established based on the potential associations determined by the pseudo-labels.

[0062] In one possible embodiment, for a newly added enterprise node, the executing entity can treat it as a weighted combination of multiple historically similar enterprise nodes based on the similarity between enterprises, thereby establishing a virtual association between the newly added enterprise node and the target historical node. For a newly added resource node or a newly added scene node, the executing entity can establish a virtual association between the newly added resource node or the newly added scene node and the target historical node based on the generated resource-scene matching pseudo-labels, so that the newly added resource node or the newly added scene node can participate in the subsequent graph neural network feature propagation process. That is, through step 301, the structural connection foundation between the newly added node and the historical node can be supplemented, thereby providing the preconditions for subsequent attention calculation and feature aggregation.

[0063] Step 302: Input the target node into the dual-path graph attention network, and use the multi-head attention mechanism to extract features from the heterogeneous graph model to obtain the feature extraction results corresponding to the target node.

[0064] Here, after establishing a virtual association between the newly added node and the target historical node, the executing entity can input the target node into a dual-path graph attention network. Through a multi-head attention mechanism, features are extracted from the heterogeneous graph model to obtain the feature extraction results corresponding to the target node. The dual-path graph attention network can be understood as a graph neural network structure designed for heterogeneous graph models, used to extract and update node features in different semantic relationship planes. For example, attention learning can be performed in the "enterprise-resource" relationship plane and the "resource-scenario" relationship plane respectively. The multi-head attention mechanism can be used to weighted model the association strength between the target node and its different neighboring nodes to learn the contribution of different neighboring nodes to the state update of the target node. By inputting the target node into the dual-path graph attention network, a unified model can be performed on the target node, neighboring nodes, and the connection relationships supplemented by the virtual association, thereby obtaining the feature extraction results corresponding to the target node.

[0065] In one possible embodiment, the executing entity can first map the original attributes of enterprise nodes, resource nodes, and scene nodes to a unified low-dimensional continuous vector space based on a type-aware transformation matrix to obtain the initial embedding representation of each type of node. Subsequently, in the dual-path graph attention network, a multi-head attention mechanism is deployed for the "enterprise-resource" subgraph and the "resource-scene" subgraph respectively to calculate the attention weight between the target node and the heterogeneous neighbor nodes. Then, based on the obtained attention weight, the feature information of the heterogeneous neighbor nodes is weighted and aggregated to obtain the feature extraction result corresponding to the target node.

[0066] In one possible embodiment, when performing feature extraction via a multi-head attention mechanism, the executing agent can also combine residual connections, gated updates, or other node state update methods to iteratively optimize the intermediate representations of the target node. This allows the target node to gradually integrate the structural semantic information carried by its neighboring nodes, target historical nodes, and virtual associations during multi-layer propagation. This approach can fully explore high-order relationships between enterprises, resources, and scenarios in heterogeneous graph models, improving the expressive power of the feature extraction results corresponding to the target node.

[0067] Step 303: Perform cross-type feature aggregation on the feature extraction results to obtain feature representation.

[0068] Here, after obtaining the feature extraction results corresponding to the target node, the executing entity can perform cross-type feature aggregation to obtain a feature representation. Cross-type feature aggregation can be understood as further fusing the feature information between different types of nodes after obtaining the feature extraction results corresponding to enterprise nodes, resource nodes, and scene nodes, to form a node feature representation that can comprehensively represent the multi-dimensional relationship between enterprises, resources, and scenes. By performing cross-type feature aggregation, the information fragmentation problem caused by extracting features only in a single type of node or a single relationship subgraph can be avoided, thereby improving the completeness and consistency of the final feature representation.

[0069] In one possible embodiment, the executing entity can jointly aggregate the feature extraction results corresponding to enterprise nodes, resource nodes, and scene nodes to form a unified feature representation for emergency dispatch tasks. For example, the executing entity can fuse the correlation information between features of different types of nodes based on a preset cross-type aggregation strategy, enabling enterprise node features to perceive the semantic information of resource nodes and scene nodes, resource node features to perceive the demand information of enterprise nodes and scene nodes, and scene node features to perceive the collaborative information of enterprise nodes and resource nodes. In this way, the final feature representation of each target node can be obtained.

[0070] In one possible embodiment, for newly added nodes that are supplemented into the graph structure via virtual associations, the executing entity can, when performing cross-type feature aggregation, also incorporate the information propagated between the newly added node and the target historical node into the joint representation process of the three types: enterprise, resource, and scenario. This allows the final feature representation of the newly added node to not only retain its own attribute features but also integrate the structural knowledge and business semantics of the historical nodes. In other words, step 303, based on steps 301 and 302, can further transform the information propagation results brought about by the virtual associations established by pseudo-labels into a stable node representation for emergency resource recommendation tasks.

[0071] Specifically, through steps 301 to 303, the executing entity can first establish a virtual association between the newly added node and the target historical node based on pseudo-labels, then use a dual-path graph attention network and a multi-head attention mechanism to extract features from the target node, and finally obtain the feature representation of each target node through cross-type feature aggregation. Thus, even when the newly added node lacks real historical interaction data, it can still obtain a relatively complete and accurate node feature representation, providing a basic support for subsequent calculation of the recommendation score corresponding to the candidate emergency resources based on the node feature representation and pseudo-labels.

[0072] In this embodiment, firstly, the execution subject establishes a virtual association between the newly added node and the target historical node based on pseudo-labels; then, the execution subject inputs the target node into a dual-path graph attention network, and performs feature extraction on the heterogeneous graph model through a multi-head attention mechanism to obtain the feature extraction result corresponding to the target node; finally, the execution subject performs cross-type feature aggregation on the feature extraction result to obtain the feature representation.

[0073] As described above, this embodiment alleviates the problem of missing structural information caused by the lack of real historical interaction relationships in newly added nodes by establishing a virtual association between the newly added nodes and the target historical nodes. This embodiment enhances the ability to represent complex relationships between enterprises, resources and scenarios by using a dual-path graph attention network and a multi-head attention mechanism to extract features from the heterogeneous graph model. Furthermore, by performing cross-type feature aggregation on the feature extraction results, the completeness and accuracy of node feature representation are improved, thereby providing support for achieving more accurate emergency resource recommendations.

[0074] Step 104: Calculate the recommendation score for each candidate emergency resource based on feature representation and pseudo-label, and then filter and sort the candidate emergency resources based on the recommendation score to obtain the target recommendation result.

[0075] Here, after obtaining the feature representations of each target node, the executing entity can calculate the recommendation score corresponding to each candidate emergency resource based on the feature representations and pseudo-labels, and then filter and sort the candidate emergency resources based on the recommendation scores to obtain the target recommendation results.

[0076] In one possible embodiment, such as Figure 4 As shown, the recommendation score for each candidate emergency resource is calculated based on feature representation and pseudo-labels, including the following steps: Step 401: Based on the feature representations of each target node, extract the enterprise representation corresponding to the enterprise node, the resource representation corresponding to the resource node, and the scene representation corresponding to the scene node.

[0077] Here, after obtaining the feature representations of each target node, the executing entity can extract the enterprise representation for enterprise nodes, the resource representation for resource nodes, and the scenario representation for scenario nodes based on these feature representations. The enterprise representation can characterize the target enterprise's supply and demand coordination capabilities, the strength of its mutual assistance relationships, and its business response capabilities under the current emergency task. The resource representation can characterize the resource attributes, scenario adaptability potential, and availability of candidate emergency resources. The scenario representation can characterize the urgency, demand characteristics, and evolutionary tendencies of the target emergency scenario. In other words, the role of this step is to further extract the enterprise representation, resource representation, and scenario representation required for subsequent scoring calculations from the target node feature representations obtained through the aforementioned heterogeneous graph learning and feature aggregation, thereby providing direct input to the recommendation decision engine.

[0078] In one possible embodiment, the enterprise representation can be directly determined by the feature representation corresponding to the enterprise node, the resource representation can be directly determined by the feature representation corresponding to the resource node, and the scene representation can be directly determined by the feature representation corresponding to the scene node. It should be understood that the above three types of representations can be either the final output vector of a single node in the graph neural network, or a task-level representation obtained by aggregating the feature representations of multiple nodes of the same type. No limitation is imposed here; the specific method used can be determined based on the number of enterprise nodes, resource nodes, and scene nodes in the current task, as well as the granularity of the recommendation decision.

[0079] Step 402: Perform feature fusion on enterprise representation, resource representation, scene representation and pseudo-label to obtain fused features.

[0080] Here, after extracting the enterprise representation corresponding to the enterprise node, the resource representation corresponding to the resource node, and the scene representation corresponding to the scene node, the executing entity can perform feature fusion on the enterprise representation, resource representation, scene representation, and pseudo-labels to obtain fused features. Feature fusion includes introducing a Hadamard product interaction term. The pseudo-labels can be resource-scene matching pseudo-labels generated by the aforementioned cold-start response mechanism, used to provide directional constraints for recommendation scoring under cold-start and sparse data conditions. The Hadamard product interaction term can be used to characterize the dimension-wise interaction relationship between different feature vectors to strengthen matching signals such as enterprise-resource and resource-scene. In other words, the purpose of this step is not only to consider the individual contributions of the enterprise representation, resource representation, and scene representation, but also to further consider the deep interaction relationship between different representations, thereby improving the expressive power and nonlinear modeling ability of recommendation scoring.

[0081] In one possible embodiment, the executing agent can concatenate the enterprise representation, resource representation, scene representation, and pseudo-labels, and further introduce Hadamard product interaction terms to obtain fused features. For example, the executing agent can introduce the Hadamard product interaction term Ze⊙Zr between the enterprise representation and the resource representation, and the Hadamard product interaction term Zr⊙Zs between the resource representation and the scene representation, to enhance the deep interaction relationship between different representations. Here, Ze can represent the enterprise representation, Zr can represent the resource representation, and Zs can represent the scene representation. In this way, while retaining the semantic information of the enterprise representation, resource representation, scene representation, and pseudo-labels individually, the matching relationship and interaction between the three can be further characterized, thereby obtaining fused features for recommendation scoring calculation.

[0082] In one possible embodiment, to make the model more closely aligned with engineering practice, the executing entity can further introduce scenario urgency, enterprise-resource supply and demand weights, and historical reliability indicators when performing feature fusion. This will enable the fused features to not only represent the semantic matching relationship between the three parties of "enterprise-resource-scenario" but also reflect the constraint information related to actual scheduling operations.

[0083] Step 403: Input the fused features into a multilayer perceptron for mapping to obtain a recommendation score.

[0084] Here, after obtaining the fused features, the executing entity can input these features into a multilayer perceptron for mapping, resulting in a recommendation score. This recommendation score characterizes the matching degree, adaptability, and scheduling priority of candidate emergency resources within the current target enterprise and target emergency scenario. In other words, the purpose of this step is to utilize the multilayer perceptron to perform a nonlinear mapping on the fused features and output a priority score corresponding to each candidate emergency resource, thereby providing a basis for subsequent candidate emergency resource selection and ranking.

[0085] In one possible embodiment, the executing agent can construct fused features based on enterprise representation, resource representation, scene representation, pseudo-labels, and interaction items, and obtain a recommendation score through a multilayer perceptron (MLP) and a sigmoid activation function. Accordingly, the recommendation score can be expressed as:

[0086] in, This represents the recommendation score given the target company e, candidate emergency resources r, and target emergency scenario s. This represents the Sigmoid activation function. and For learnable parameters, , and These represent enterprise representation, resource representation, and scenario representation, respectively. This indicates a pseudo-tag for resources and scenarios. This represents the Hadamard product operation. Through the above method, a non-linear scoring of the semantic matching relationship between enterprises, resources, and scenarios can be achieved.

[0087] Specifically, after obtaining the recommended score for a single candidate emergency resource, the implementing entity can also traverse the set of candidate emergency resources under the current task to obtain the corresponding score vector. Accordingly, the score vector can be represented as:

[0088] in, Let represent the candidate emergency resource scoring vector for target enterprise e and target emergency scenario s. Let represent the recommended score corresponding to the i-th candidate emergency resource. By forming a score vector, we can provide the input basis for filtering and ranking subsequent candidate emergency resources.

[0089] In this embodiment, firstly, the executing entity extracts the enterprise representation corresponding to the enterprise node, the resource representation corresponding to the resource node, and the scene representation corresponding to the scene node based on the feature representation of each target node; then, the executing entity performs feature fusion on the enterprise representation, resource representation, scene representation, and pseudo-label to obtain fused features; finally, the executing entity inputs the fused features into a multilayer perceptron for mapping and processes them through a sigmoid activation function to obtain a recommendation score.

[0090] As described above, this embodiment achieves multi-dimensional feature representation of target enterprises, candidate emergency resources, and target emergency scenarios by extracting enterprise representation, resource representation, and scenario representation. By fusing features from enterprise representation, resource representation, scenario representation, and pseudo-labels, and introducing Hadamard product interaction terms, the ability to represent the interaction relationships between enterprises and resources, and between resources and scenarios, is enhanced. By inputting the fused features into a multilayer perceptron for mapping, the matching relationship between candidate emergency resources and target enterprises and target emergency scenarios can be effectively evaluated, thereby improving the accuracy of the recommendation scoring results and providing a reliable basis for subsequent screening and ranking of emergency resources. This, in turn, improves the accuracy, rationality, and timeliness of emergency resource recommendation results.

[0091] In one possible embodiment, such as Figure 5 As shown, the process of filtering and ranking candidate emergency resources based on recommendation scores to obtain target recommendation results includes the following steps: Step 501: Based on the upper limit of response time, the upper limit of transportation distance, and inventory constraints, filter the candidate emergency resources to obtain the target candidate resources.

[0092] Here, after receiving the recommendation score, the executing entity can filter candidate emergency resources based on response time caps, transportation distance caps, and inventory constraints to obtain target candidate resources. The response time cap constrains the latest acceptable arrival time of candidate emergency resources under the current emergency task; the transportation distance cap constrains the maximum acceptable transportation distance between the resource location and the target enterprise or target scenario location; and the inventory constraint constrains the current available inventory or deployable quantity of candidate emergency resources. In other words, the purpose of this step is to initially eliminate candidate emergency resources based on the rigid business constraints in emergency scheduling, preventing resources that do not meet the basic scheduling conditions from entering the subsequent sorting stage, thereby ensuring that the subsequent sorting is conducted within the scope of executable resources.

[0093] In one possible embodiment, the executing entity can determine for each candidate emergency resource whether its estimated response time exceeds a preset response time limit, whether its transportation distance exceeds a preset transportation distance limit, and whether its resource inventory meets the current task requirements. When any candidate emergency resource does not meet any of the above constraints, the executing entity can remove that candidate emergency resource from the candidate set, thereby obtaining the target candidate resource. It should be understood that the response time limit, transportation distance limit, and inventory constraints can be preset by business rules or dynamically determined according to the urgency of the task, resource type, and enterprise needs, and are not limited here.

[0094] Specifically, the implementing entity can estimate the expected response time and transportation distance of candidate emergency resources based on their current geographical location, transportation mode, resource preparation time, and the location of the target enterprise or target emergency scenario. Simultaneously, the implementing entity can determine whether the candidate emergency resources meet the quantity requirements of the current emergency task based on inventory status information in the resource management system. Through this method, the implementing entity can eliminate resource items that are not feasible, thereby obtaining target candidate resources that meet the basic scheduling conditions.

[0095] Step 502: Based on the recommendation score, transportation cost, and resource scarcity weight, sort the target candidate resources to obtain a target resource list.

[0096] Here, after obtaining the target candidate resources, the implementing entity can sort the target candidate resources based on recommendation scores, transportation costs, and resource scarcity weights to obtain a target resource list. The recommendation score characterizes the matching degree between the candidate emergency resources and the target enterprise and target emergency scenario; the transportation cost characterizes the implementation cost of resource allocation; and the resource scarcity weight characterizes the scarcity level of the candidate emergency resources. Through this method, the priority of target candidate resources can be further differentiated while meeting basic scheduling conditions.

[0097] In one possible implementation, the executing entity can first perform hard-constraint filtering on candidate emergency resources based on response time limits, transportation distance limits, and inventory constraints, eliminating resource items that do not meet the conditions. Then, based on recommendation scores, transportation costs, and resource scarcity weights, it can perform soft-constraint ranking on the remaining resources to obtain the target resource list. It should be understood that the executing entity can also combine enterprise mutual assistance weights or scarce resource penalty factors to modify the ranking results, which is not limited here.

[0098] In one possible embodiment, after the execution entity completes the sorting, it can select the top K candidate emergency resources from the sorting results and output the final Top-K resource list. In other words, the target resource list can be a resource list truncated by a preset number K, which is used to represent the several candidate emergency resources with the highest priority under the current task.

[0099] Step 503: Determine the target resource list as the target recommendation result.

[0100] Here, after obtaining the target resource list, the executing entity can determine the target resource list as the target recommendation result. The target recommendation result can be understood as the executable resource recommendation result output for the current emergency task, which is used to indicate which candidate emergency resources have higher matching priority and allocation feasibility under the current target enterprise and target emergency scenario.

[0101] In one possible embodiment, the target recommendation result may include the final Top-K resource list and its priority ranking. Furthermore, the target recommendation result may also include information such as recommendation priority, scheduling source, expected response time, and adaptation explanation field, without limitation.

[0102] In this embodiment, firstly, the executing entity filters candidate emergency resources based on response time limits, transportation distance limits, and inventory constraints to obtain target candidate resources; then, the executing entity sorts the target candidate resources based on recommendation scores, transportation costs, and resource scarcity weights to obtain a target resource list; finally, the executing entity determines the target resource list as the target recommendation result.

[0103] As described above, this embodiment filters candidate emergency resources by applying hard constraints, eliminating resource items that do not meet response time limits, transportation distance limits, or inventory constraints, thus ensuring that resources entering the subsequent sorting stage have basic executability. By sorting target candidate resources based on recommendation scores, transportation costs, and resource scarcity weights, a more reasonable list of target resources with higher priorities can be obtained while satisfying scheduling constraints, taking into account resource matching degree, allocation cost, and resource scarcity. By determining the target resource list as the target recommendation result, an executable resource recommendation output for the current emergency task can be generated, thereby improving the accuracy, rationality, and timeliness of emergency resource recommendation results, and ultimately improving emergency resource allocation efficiency and emergency response capabilities.

[0104] This disclosure provides an emergency resource recommendation method, apparatus, device, medium, and product. First, task data is acquired, including target enterprise data, candidate emergency resource data, and target emergency scenario data. Then, the task data is mapped to a heterogeneous graph model to determine the target nodes corresponding to the task data. Next, pseudo-labels are determined based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model. Features of the target nodes are then aggregated based on the pseudo-labels to obtain feature representations for each target node. Finally, recommendation scores are calculated for each candidate emergency resource based on the feature representations and pseudo-labels. The candidate emergency resources are then filtered and ranked based on the recommendation scores to obtain the target recommendation results.

[0105] As described above, this embodiment of the present disclosure maps target enterprise data, candidate emergency resource data, and target emergency scenario data into a heterogeneous graph model to determine target nodes corresponding to task data, thereby achieving a unified representation of enterprises, resources, and scenarios. Based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, pseudo-labels are determined, and feature aggregation is performed on the target nodes based on these pseudo-labels. This alleviates the problem of missing features caused by the lack of historical interaction data for newly added enterprise nodes, resource nodes, or scenario nodes, and improves the completeness of the target node feature representation. Based on the feature representation and pseudo-labels, recommendation scores are calculated for each candidate emergency resource, and candidate emergency resources are screened and ranked based on these recommendation scores. This achieves an effective evaluation of the matching relationship between candidate emergency resources and target enterprises and target emergency scenarios, thereby improving the accuracy, rationality, and timeliness of emergency resource recommendation results, and ultimately improving the efficiency of emergency resource allocation and emergency response capabilities.

[0106] In one possible embodiment, such as Figure 6 As shown, before mapping task data to a heterogeneous graph model and determining the target node corresponding to the task data, the following steps are also included: Step 601: Obtain multi-source data.

[0107] Here, before mapping task data to the heterogeneous graph model and determining the target nodes corresponding to the task data, the executing entity can acquire multi-source data. This multi-source data includes enterprise data, emergency resource data, and emergency scenario data. Multi-source data can be understood as the foundational data used to build the heterogeneous graph model, representing the original information of the enterprise entities, candidate resources, and emergency scenarios involved in the emergency dispatching process of coal-fired power plants. In other words, the purpose of this step is to provide data sources for the subsequent construction of enterprise node sets, resource node sets, and scenario node sets, and further provide basic support for the establishment of heterogeneous edge sets and heterogeneous graph models. It should be understood that multi-source data can originate from internal enterprise business systems, as well as external monitoring systems, resource management systems, or emergency management platforms; no restrictions are placed here.

[0108] In one possible embodiment, enterprise data may include data from key entities such as coal mines, power plants, and dispatch centers, including production load, resource reserve capacity, geographic location, and emergency response level. Emergency resource data may include data on emergency coal supply, core spare parts, emergency repair technicians, and special vehicles, including resource specifications, dynamic inventory status, lead time for deployment, and spatial distribution. Emergency scenario data may include scenario data such as unplanned equipment outages, fuel supply interruptions, natural disasters, and production safety accidents, including scenario semantic tags, urgency level, spatiotemporal impact range, and evolution probability, without limitation. By acquiring the above multi-source data, the key elements involved in the emergency dispatch tasks of coal-fired power plants can be comprehensively described from three dimensions: enterprise, resources, and scenarios, providing a unified data foundation for subsequent heterogeneous graph modeling.

[0109] Specifically, the implementing entity can obtain relevant data from enterprise resource planning systems, scheduling management systems, warehouse management systems, vehicle scheduling systems, monitoring and alarm systems, and emergency response systems. The acquired data undergoes preprocessing operations such as cleaning, format standardization, missing value handling, and outlier removal to obtain multi-source data that can be used for subsequent node construction and graph structure modeling. It should be understood that the above preprocessing methods can be flexibly configured according to the characteristics of different data sources, and no restrictions are imposed here.

[0110] Step 602: Construct enterprise node set, resource node set and scenario node set based on multi-source data.

[0111] Here, after acquiring multi-source data, the executing entity can construct enterprise node sets, resource node sets, and scenario node sets based on this data. The enterprise node set represents the set of enterprise entities in an emergency dispatch scenario, the resource node set represents the set of available emergency resources, and the scenario node set represents the set of emergency scenarios to be handled. In other words, the purpose of this step is to uniformly transform enterprise entities, resource entities, and scenario entities in the multi-source data into node objects in a graph structure, so that subsequent relationships between different types of nodes can be established within a unified topology space. It should be understood that the number of nodes in the node sets can be dynamically determined based on the number of enterprises, resources, and scenarios in the actual business scenario, and is not limited here.

[0112] In one possible embodiment, the executing entity can perform feature vectorization encoding on enterprise data to obtain a set of enterprise nodes. Each enterprise node in the enterprise node set can correspond to an enterprise entity. The attribute vector of the enterprise node can include information such as real-time production load, resource reserve threshold, geospatial coordinates, and emergency response level, which are used to characterize the enterprise's supply and demand capacity and coordination capability in current or historical emergency tasks.

[0113] In one possible embodiment, the executing entity can also perform feature vectorization encoding on the candidate emergency resource data to obtain a resource node set. Each resource node in the resource node set can correspond to a candidate emergency resource. The attribute vector of the resource node can include information such as resource specifications, dynamic inventory status, call lead time, and spatial distribution, which are used to characterize the availability and allocation capability of the resource.

[0114] In one possible embodiment, the executing entity can also perform feature vectorization encoding on the target emergency scenario data to obtain a scenario node set. Each scenario node in the scenario node set can correspond to an emergency scenario. The attribute vector of the scenario node can include information such as scenario semantic labels, the degree of urgency, the spatiotemporal impact range, and the evolution probability, which are used to characterize the demand characteristics and evolution trend of the scenario.

[0115] Specifically, the executing entity can adopt unified or different encoding strategies for different types of data. For example, the executing entity can normalize numerical attributes, embed categorical attributes, and semantically vectorize textual scene descriptions, thereby enabling enterprise nodes, resource nodes, and scene nodes to be uniformly represented in vector form. Through this approach, the subsequent heterogeneous edge construction and graph neural network learning processes can be carried out within a unified feature space.

[0116] Step 603: Construct a heterogeneous edge set based on the relationships between the enterprise node set, resource node set, and scenario node set.

[0117] Here, after constructing the enterprise node set, resource node set, and scenario node set, the executing entity can build a heterogeneous edge set based on the relationships between these sets. This heterogeneous edge set can be used to represent the multidimensional semantic relationships between different types of nodes, thus transforming enterprise nodes, resource nodes, and scenario nodes from isolated sets into a graph structure that reflects the actual emergency dispatch logic. In other words, the purpose of this step is to structurally model the relationships between multiple types of nodes based on the business collaboration logic in the emergency dispatch of coal-fired power plants, thereby providing the edge connection foundation for the subsequent establishment of the heterogeneous graph model.

[0118] In one possible embodiment, the heterogeneous edge set can include supply-demand association edges, resource-scenario adaptation edges, and enterprise-enterprise collaboration edges. Specifically, the executing entity can construct supply-demand association edges based on the affiliation, supply-demand relationship, or service relationship between enterprise nodes and resource nodes to represent the supply or demand connection between the enterprise entity and emergency resources; the executing entity can also construct resource-scenario adaptation edges based on the adaptation relationship between resource nodes and scenario nodes to represent the applicability of a specific resource to a specific emergency scenario; the executing entity can also construct enterprise-enterprise collaboration edges based on the resource mutual assistance relationship, business collaboration relationship, or scheduling collaboration relationship between enterprise nodes to represent the collaborative scheduling capability and mutual assistance strength among different enterprise entities. Through the above methods, the heterogeneous edge set can represent the complex relationship network in the emergency scheduling scenario of coal-fired power plant joint ventures from multiple dimensions.

[0119] In one possible embodiment, when constructing a heterogeneous edge set, the executing entity can also assign edge weights to the heterogeneous edges based on the business semantics corresponding to different edge types. For example, the edge weight of a supply-demand related edge can be determined based on the supply and demand intensity between the enterprise and the resource; the edge weight of a resource-scenario adaptation edge can be determined based on the resource's adaptability to the scenario; and the edge weight of an enterprise-enterprise collaboration edge can be determined based on the frequency of collaboration, the degree of mutual assistance, or the scheduling success rate between enterprises, without any restrictions. By setting edge weights for heterogeneous edges, the subsequent heterogeneous graph learning process can more accurately reflect the degree of influence of different relationships on node state updates. For example, the edge weight of a supply-demand related edge can be derived from a cost function jointly determined by the real-time availability of resources and logistics transportation costs, such as distance and duration; the edge weight of a resource-scenario adaptation edge can be modeled based on the cosine similarity between resource functional attributes and scenario requirements, as well as historical scheduling success rates; and the edge weight of an enterprise-enterprise collaboration edge can be dynamically assigned based on historical collaboration frequency, geographical proximity, and organizational affiliation.

[0120] Specifically, after completing the construction of the heterogeneous edge set, the executing entity can organize the various types of connection relationships between the enterprise node set, resource node set, and scene node set into a unified edge set in the graph structure. This enables the subsequent heterogeneous graph model to simultaneously express the three core relationships of enterprise-resource, resource-scene, and enterprise-enterprise, providing relational semantic support for subsequent node representation learning and emergency resource recommendation.

[0121] Step 604: Establish a heterogeneous graph model based on the enterprise node set, resource node set, scenario node set, and heterogeneous edge set.

[0122] Here, after obtaining the enterprise node set, resource node set, scenario node set, and heterogeneous edge set, the executing entity can establish a heterogeneous graph model based on these elements. This heterogeneous graph model can be understood as a structured graph model within a unified topological space, used to comprehensively represent the multidimensional relationships and interaction logic between the enterprise entity, candidate emergency resources, and emergency scenarios. In other words, the purpose of this step is to unify and integrate the aforementioned node set and edge set, forming the graph structure foundation upon which subsequent task data mapping, cold-start node identification, feature propagation, and recommendation scoring calculation rely.

[0123] In one possible embodiment, the executing entity can use the enterprise node set, resource node set, and scenario node set as the node set in the heterogeneous graph model, and use the supply-demand association edge, resource-scenario adaptation edge, and enterprise-enterprise collaboration edge as the edge set in the heterogeneous graph model, thereby constructing an "enterprise-resource-scenario" heterogeneous graph model. This heterogeneous graph model can uniformly represent the entities and their relationships in the emergency dispatch process of coal-fired power joint ventures from three dimensions: enterprise entity, resource entity, and emergency scenario. This enables the subsequent graph neural network to learn the high-order association features between nodes in a unified topological space.

[0124] In one possible embodiment, after establishing the heterogeneous graph model, the executing entity can also uniformly store and manage the node attribute matrix, edge weight matrix, and relation type identifier in the heterogeneous graph model, so as to quickly retrieve them in subsequent task data mapping, cold start node identification, and graph attention calculation processes. It should be understood that the heterogeneous graph model can be stored in the form of a static graph or constructed into a dynamically updatable graph structure according to business needs, without any limitation.

[0125] Specifically, through steps 601 to 604, the executing entity can first acquire multi-source data such as enterprise data, emergency resource data, and emergency scenario data, then construct enterprise node sets, resource node sets, and scenario node sets, further construct heterogeneous edge sets based on the relationships between nodes, and finally establish a heterogeneous graph model. This provides a model foundation for subsequently mapping task data to the heterogeneous graph model, determining the target nodes corresponding to the task data, and performing pseudo-label generation and resource recommendation scoring.

[0126] In one possible embodiment, such as Figure 7 As shown, Figure 7 An exemplary diagram of the overall technical framework of an emergency resource recommendation system is shown. After establishing the heterogeneous graph model, task data mapping, cold start node processing, graph structure feature learning, and recommendation decision optimization can be further performed based on the heterogeneous graph model, thereby forming the overall processing flow of emergency resource recommendation. Specifically, Figure 7 The overall technical framework shown can include three parts: heterogeneous graph construction and data mapping, graph neural network computing engine, and recommendation decision engine and scheduling optimization.

[0127] In the heterogeneous graph construction and data mapping section, the executing entity can first acquire multi-source data such as enterprise data, emergency resource data, and emergency scenario data. Based on this multi-source data, it constructs enterprise node sets, resource node sets, and scenario node sets. Further, based on the relationships between these sets, it constructs heterogeneous edge sets, thereby establishing a heterogeneous graph model. On this basis, the executing entity can also acquire task data and map it to the heterogeneous graph model to determine the target nodes corresponding to the task data. These target nodes can include enterprise nodes, resource nodes, and scenario nodes. Figure 7 The part shown on the left corresponds to the execution process of steps 601 to 604 and steps 101 and 102 mentioned above.

[0128] In the graph neural network computation engine, the execution entity can determine pseudo-labels based on the similarity between newly added nodes in the target node and historical nodes in the heterogeneous graph model. Based on these pseudo-labels, a virtual association is established between the newly added node and the target historical node to alleviate the cold start problem caused by the lack of historical interaction data for the newly added node. Subsequently, the execution entity can input the target node into a dual-path graph attention network, extract features from the heterogeneous graph model through a multi-head attention mechanism, and combine cross-type feature aggregation to obtain the feature representation of each target node. It should be understood that... Figure 7The “cold start response mechanism,” “two-layer graph attention network architecture,” “hierarchical aggregation and state update,” and “cross-type feature fusion and collaborative evolution” can all be regarded as specific implementations of pseudo-label generation, feature propagation, feature extraction, and feature aggregation for newly added nodes in this disclosure, which correspond to the aforementioned steps 103, 201 to 203, and 301 to 303.

[0129] In the recommendation decision engine and scheduling optimization section, the executing entity can extract the enterprise representation corresponding to the enterprise node, the resource representation corresponding to the resource node, and the scene representation corresponding to the scene node based on the feature representation of each target node. This is then combined with pseudo-labels for feature fusion to obtain fused features. Next, the executing entity can calculate the recommendation score for each candidate emergency resource based on the fused features, filter the candidate emergency resources based on response time limits, transportation distance limits, and inventory constraints, and then rank the target candidate resources based on the recommendation score, transportation cost, and resource scarcity weight, thereby obtaining a target resource list. This target resource list is then determined as the target recommendation result. In other words, Figure 7 The part shown on the right corresponds to the execution process of steps 401 to 403 and steps 501 to 503 mentioned above.

[0130] thus, Figure 7 The overall technical framework shown can organically connect heterogeneous graph modeling driven by multi-source data, cold start node compensation based on pseudo-labels, feature learning of dual-path graph attention network, and resource recommendation decision-making for emergency tasks, thus forming a complete processing flow from heterogeneous graph model establishment, task node mapping, node feature representation to resource recommendation result output.

[0131] In one possible embodiment, to verify the effectiveness and applicability of the proposed heterogeneous graph-based emergency resource recommendation method for coal-fired power plant joint ventures in actual emergency dispatch scenarios, real emergency dispatch data from coal-fired power plant joint ventures in a certain region can be selected for experimental verification. Under unified training and evaluation conditions, the method of this disclosure can be compared with multiple comparative methods. The comparative methods can include traditional recommendation models, such as UserCF and CBR; ordinary graph neural network models, such as GCN and GAT; classic heterogeneous graph learning models, such as HGAT and MP-GNN; and industry-adapted or advanced models, such as RES, DHGAT, LAG, and XSimGCL, etc. There are no restrictions here. The evaluation index can be the recall index Recall@topK commonly used in recommendation tasks, which is used to measure the system's ability to cover real available resources in the candidate resource set. The value of K can be extended according to different recommendation scales. In this embodiment, Recall@top5 can be used as an example for comparison and demonstration.

[0132] In one possible embodiment, the main experimental results can be as follows: Figure 8 As shown, Figure 8 An exemplary diagram comparing experimental results is shown. Figure 8 This paper demonstrates the performance differences of various comparative methods on the Recall@top5 metric under the same dataset and evaluation criteria. Experimental results show that the proposed method, ERCECHG, achieves the best performance on the Recall@top5 metric, reaching 94.0%, significantly outperforming traditional recommendation models and various graph learning methods. This result indicates that the proposed method can cover more real and usable emergency resources in the candidate resource recommendation list, thus possessing stronger resource hit rate and emergency dispatch support value.

[0133] Furthermore, the experimental results show that compared to traditional recommendation methods such as UserCF and CBR, the proposed method significantly improves the Recall@top5 metric. This indicates that traditional recommendation methods, which rely more on user similarity or rule matching, struggle to effectively depict the complex relationships between organizations and entities within coal-fired power plants, resulting in limited recommendation coverage. In contrast, the proposed method uses a unified model based on a heterogeneous graph of "enterprise-resource-scenario," which can explicitly express enterprise supply and demand relationships, resource matching relationships, and mutual cooperation relationships. Therefore, it exhibits higher resource coverage under complex industrial chain conditions.

[0134] Meanwhile, compared to ordinary graph neural network models such as GCN and GAT, the method disclosed in this paper shows a more significant advantage in heterogeneous relationship modeling. Although ordinary graph neural network models can improve recommendation performance by utilizing graph structure information, they are mainly applicable to homogeneous graph scenarios and are difficult to differentiate in modeling relationships of multiple node types and multiple sides in coal-fired power emergency tasks. In contrast, the method disclosed in this paper uses heterogeneous graph structures and attention mechanisms to weight and learn different relationships, which can more accurately characterize the enterprise-resource supply and demand logic and the resource-scenario adaptation logic, thus achieving better results in recommendation accuracy and resource coverage.

[0135] Furthermore, compared with classic heterogeneous graph models and advanced models such as HGAT, MP-GNN, LAG, and XSimGCL, the method disclosed herein maintains a stable leading position. This indicates that the method not only possesses good heterogeneous relationship modeling capabilities but also exhibits stronger industry adaptability and comprehensive modeling capabilities in the emergency dispatching scenario of coal-fired power plants, enabling it to more effectively handle resource recommendation problems under conditions of multi-entity collaboration, multiple resource constraints, and dynamic changes in multiple scenarios.

[0136] In summary, the experimental comparison results show that the method proposed in this publication can significantly improve the recall performance in emergency resource recommendation tasks and achieve a higher proportion of effective resource coverage, thus demonstrating good engineering practical value and application prospects in the emergency dispatch scenario of coal-fired power plants.

[0137] By dividing each functional module according to its corresponding function, this disclosure provides an emergency resource recommendation device, which can be a server or a chip applied to a server. Figure 9 A schematic block diagram of the functional modules of an emergency resource recommendation device provided as an exemplary embodiment of this disclosure. (See diagram below.) Figure 9 As shown, the emergency resource recommendation device includes: The first acquisition module 901 is used to acquire task data; the task data includes target enterprise data, candidate emergency resource data, and target emergency scenario data. The determination module 902 is used to map the task data to a heterogeneous graph model and determine the target node corresponding to the task data; The aggregation module 903 is used to determine pseudo-labels based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, and to perform feature aggregation on the target nodes based on the pseudo-labels to obtain feature representations of each target node. The recommendation module 904 is used to calculate the recommendation score corresponding to each candidate emergency resource based on the feature representation and the pseudo label, and to filter and sort the candidate emergency resources based on the recommendation score to obtain the target recommendation result.

[0138] In one embodiment, determining module 902 includes: The first encoding unit is used to perform feature vectorization encoding on the target enterprise data to obtain enterprise nodes; The second encoding unit is used to perform feature vectorization encoding on the candidate emergency resource data to obtain resource nodes; The third encoding unit is used to perform feature vectorization encoding on the target emergency scene data to obtain scene nodes; The first mapping unit is used to map the enterprise node, the resource node and the scene node to the heterogeneous graph model to obtain the target node.

[0139] In one embodiment, the aggregation module 903 includes: The fourth encoding unit is used to perform feature encoding and normalization processing on the newly added node to obtain the attribute embedding vector corresponding to the newly added node; wherein, the newly added node includes at least one of the newly added enterprise node, newly added resource node and newly added scene node; The calculation unit is used to obtain the embedding representation of each of the historical nodes, and calculate the similarity between the attribute embedding vector and each of the embedding representations to obtain the similarity calculation result between the new node and each of the historical nodes; The first determining unit is used to determine the pseudo-label based on the similarity calculation result.

[0140] In one embodiment, the aggregation module 903 includes: The filtering unit is used to filter out a preset number of historical nodes with the highest similarity to the newly added node from the historical nodes based on the similarity calculation results, so as to obtain the target historical node; The first construction unit is used to construct pseudo-label determination rules based on the historical scheduling information and resource scenario matching information of the target historical node. The second determining unit is used to determine the pseudo-label based on the pseudo-label determination rule.

[0141] In one embodiment, the aggregation module 903 includes: The second construction unit is used to establish a virtual association between the newly added node and the target historical node based on the pseudo-label; wherein the virtual association is used to characterize the virtual interaction relationship between the newly added node and the target historical node; The feature extraction unit is used to input the target node into the dual-path graph attention network, and extract features from the heterogeneous graph model through a multi-head attention mechanism to obtain the feature extraction result corresponding to the target node; An aggregation unit is used to perform cross-type feature aggregation on the feature extraction results to obtain the feature representation.

[0142] In one embodiment, the recommendation module 904 includes: The extraction unit is used to extract, based on the feature representations of each target node, the enterprise representation corresponding to the enterprise node, the resource representation corresponding to the resource node, and the scene representation corresponding to the scene node; A fusion unit is used to perform feature fusion on the enterprise representation, the resource representation, the scene representation, and the pseudo-label to obtain fused features; wherein, the feature fusion includes introducing a Hadamard product interaction term; The second mapping unit is used to input the fused features into a multilayer perceptron for mapping to obtain the recommendation score.

[0143] In one embodiment, the recommendation module 904 includes: The filtering unit is used to filter the candidate emergency resources based on the upper limit of response time, the upper limit of transportation distance, and the inventory constraint to obtain the target candidate resources; The sorting unit is used to sort the target candidate resources based on the recommendation score, transportation cost, and resource scarcity weight to obtain a target resource list; The third determining unit is used to determine the target resource list as the target recommendation result.

[0144] In one embodiment, the apparatus further includes: The second acquisition module is used to acquire multi-source data, wherein the multi-source data includes enterprise data, emergency resource data, and emergency scenario data; The first construction module is used to construct an enterprise node set, a resource node set, and a scenario node set based on the multi-source data; The second construction module is used to construct a heterogeneous edge set based on the association relationship between the enterprise node set, the resource node set, and the scene node set; The third construction module is used to establish the heterogeneous graph model based on the enterprise node set, the resource node set, the scene node set, and the heterogeneous edge set.

[0145] Figure 10 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this disclosure. For example... Figure 10 As shown, the electronic device 1000 includes at least one processor 1001 and a memory 1002 coupled to the processor 1001. The processor 1001 can perform the corresponding steps in the methods disclosed in the embodiments of this disclosure.

[0146] The processor 1001 described above can also be called a central processing unit (CPU), which can be an integrated circuit chip with signal processing capabilities. Each step in the method disclosed in this embodiment can be implemented by the integrated logic circuitry in the processor 1001 or by software instructions. The processor 1001 can be a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this embodiment can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in the memory 1002, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor 1001 reads information from the memory 1002 and, in conjunction with its hardware, completes the steps of the method described above.

[0147] Furthermore, various operations / processes according to this disclosure, implemented via software and / or firmware, can be transmitted from a storage medium or network to a computer system with a dedicated hardware architecture, such as... Figure 11 The computer system 1100 shown is equipped with the programs that constitute the software. When various programs are installed, the computer system is able to perform various functions, including functions such as those described above. Figure 11 A block diagram of a computer system provided for an exemplary embodiment of this disclosure.

[0148] Computer system 1100 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0149] like Figure 11As shown, the computer system 1100 includes a computing unit 1101, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 1102 or a computer program loaded into random access memory (RAM) 1103 from a storage unit 1108. The RAM 1103 may also store various programs and data required for the operation of the computer system 1100. The computing unit 1101, ROM 1102, and RAM 1103 are interconnected via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0150] Multiple components in computer system 1100 are connected to I / O interface 1105, including: input unit 1106, output unit 1107, storage unit 1108, and communication unit 1109. Input unit 1106 can be any type of device capable of inputting information into computer system 1100. Input unit 1106 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 1107 can be any type of device capable of presenting information and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 1108 may include, but is not limited to, hard disks and optical disks. Communication unit 1109 allows computer system 1100 to exchange information / data with other devices via a network such as the Internet, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0151] The computing unit 1101 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1101 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1101 performs the various methods and processes described above. For example, in some embodiments, the methods disclosed in this disclosure can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1108. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 1000 via ROM 1102 and / or communication unit 1109. In some embodiments, the computing unit 1101 can be configured to perform the methods disclosed in this disclosure by any other suitable means (e.g., by means of firmware).

[0152] This disclosure also provides a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the methods disclosed in this disclosure.

[0153] The computer-readable storage medium in this disclosure can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The aforementioned computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specifically, the aforementioned computer-readable storage medium may include electrical connections based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0154] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0155] Figure 12 A computer program product 1200 is provided as an exemplary embodiment of the present disclosure. The computer program product 1200 includes a computer program 1201, wherein the computer program 1201, when executed by a processor, implements the methods disclosed in the embodiments of the present disclosure.

[0156] In embodiments of this disclosure, computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer.

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0158] The modules, components, or units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules, components, or units do not necessarily constitute a limitation on the module, component, or unit itself.

[0159] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0160] The above description is merely an embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0161] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. An emergency resource recommendation method, characterized in that, The method includes: Acquire task data; the task data includes target enterprise data, candidate emergency resource data, and target emergency scenario data; The task data is mapped to a heterogeneous graph model to determine the target node corresponding to the task data; Pseudo-labels are determined based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, and feature aggregation is performed on the target nodes based on the pseudo-labels to obtain the feature representation of each target node. Based on the feature representation and the pseudo-label, a recommendation score is calculated for each candidate emergency resource. The candidate emergency resources are then filtered and sorted based on the recommendation score to obtain the target recommendation result.

2. The method according to claim 1, characterized in that, The step of mapping the task data to a heterogeneous graph model and determining the target node corresponding to the task data includes: The target enterprise data is encoded using feature vectorization to obtain enterprise nodes; The candidate emergency resource data is encoded using feature vectorization to obtain resource nodes; The target emergency scenario data is encoded using feature vectorization to obtain scenario nodes; The enterprise node, the resource node, and the scene node are mapped to the heterogeneous graph model to obtain the target node.

3. The method according to claim 2, characterized in that, The process of determining pseudo-labels based on the similarity between newly added nodes in the target node and historical nodes in the heterogeneous graph model includes: The newly added nodes are subjected to feature encoding and normalization to obtain the attribute embedding vector corresponding to the newly added nodes; wherein, the newly added nodes include at least one of newly added enterprise nodes, newly added resource nodes, and newly added scene nodes; Obtain the embedding representation of each of the historical nodes, and calculate the similarity between the attribute embedding vector and each of the embedding representations to obtain the similarity calculation result between the new node and each of the historical nodes; The pseudo-label is determined based on the similarity calculation results.

4. The method according to claim 3, characterized in that, Determining the pseudo-label based on the similarity calculation result includes: Based on the similarity calculation results, a preset number of historical nodes with the highest similarity to the newly added node are selected from the historical nodes to obtain the target historical node; Based on the historical scheduling information and resource scenario matching information of the target historical node, a pseudo-label determination rule is constructed. The pseudo-label is determined based on the pseudo-label determination rule.

5. The method according to claim 4, characterized in that, The step of aggregating features of the target nodes based on the pseudo-labels to obtain feature representations of each target node includes: Based on the pseudo-tag, a virtual association is established between the newly added node and the target historical node; wherein, the virtual association is used to characterize the virtual interaction relationship between the newly added node and the target historical node; The target node is input into a dual-path graph attention network, and the heterogeneous graph model is subjected to feature extraction through a multi-head attention mechanism to obtain the feature extraction result corresponding to the target node. The feature extraction results are subjected to cross-type feature aggregation to obtain the feature representation.

6. The method according to claim 2, characterized in that, The step of calculating the recommendation score corresponding to each candidate emergency resource based on the feature representation and the pseudo-label includes: Based on the feature representations of each target node, extract the enterprise representation corresponding to the enterprise node, the resource representation corresponding to the resource node, and the scene representation corresponding to the scene node; The enterprise representation, resource representation, scene representation, and pseudo-label are fused to obtain fused features; wherein, the feature fusion includes introducing a Hadamard product interaction term; The fused features are input into a multilayer perceptron for mapping to obtain the recommendation score.

7. The method according to claim 1, characterized in that, The process of filtering and ranking the candidate emergency resources based on the recommendation score to obtain the target recommendation result includes: Based on the upper limit of response time, the upper limit of transportation distance, and inventory constraints, the candidate emergency resources are filtered to obtain the target candidate resources; Based on the recommendation score, transportation cost, and resource scarcity weight, the target candidate resources are sorted to obtain a target resource list; The list of target resources is determined as the target recommendation result.

8. The method according to claim 1, characterized in that, Before mapping the task data to a heterogeneous graph model and determining the target node corresponding to the task data, the method further includes: Acquire multi-source data, including enterprise data, emergency resource data, and emergency scenario data; Based on the multi-source data, construct enterprise node sets, resource node sets, and scenario node sets; Based on the relationships between the enterprise node set, the resource node set, and the scene node set, a heterogeneous edge set is constructed. The heterogeneous graph model is established based on the enterprise node set, the resource node set, the scene node set, and the heterogeneous edge set.

9. An emergency resource recommendation device, characterized in that, include: The first acquisition module is used to acquire task data; The task data includes target enterprise data, candidate emergency resource data, and target emergency scenario data; The determination module is used to map the task data to a heterogeneous graph model and determine the target node corresponding to the task data; An aggregation module is used to determine pseudo-labels based on the similarity between newly added nodes in the target nodes and historical nodes in the heterogeneous graph model, and to perform feature aggregation on the target nodes based on the pseudo-labels to obtain feature representations of each target node. The recommendation module is used to calculate the recommendation score corresponding to each candidate emergency resource based on the feature representation and the pseudo-label, and to filter and sort the candidate emergency resources based on the recommendation score to obtain the target recommendation result.

10. An electronic device, characterized in that, include: At least one processor; Memory for storing the at least one processor-executable instruction; The at least one processor is configured to execute the instructions to implement the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1-8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-8.

Images