A resource coordination scheduling method combining ontology model and large model

Abstract

This application discloses a resource collaborative scheduling method that integrates ontology models and large-scale models, primarily relating to the field of collaborative scheduling technology. It addresses the problems of existing solutions, such as coarse text segmentation and a lack of precise perception of core scheduling elements in identification extraction and relation completion. The method includes: calculating relation scores for candidate relations based on constraint violation factors using a trained resource constraint graph neural network; completing candidate relations between node combinations in the initial scheduling graph based on relation scores, a pre-set resource constraint table, and the trained resource constraint graph neural network, obtaining a completed scheduling graph; generating corresponding concept classes, object attributes, and data attributes based on the complete scheduling graph; generating corresponding concept axioms, relation axioms, and scheduling rules with time-delay windows based on the complete scheduling graph and the pre-set resource constraint table, unifying them into a deployable scheduling domain ontology; and deploying the scheduling domain ontology into a resource collaborative scheduling system.

Description

Technical Field

[0001] This application relates to the field of resource collaborative scheduling technology, and in particular to a resource collaborative scheduling method that integrates ontology models and large models. Background Technology

[0002] In the field of text processing and knowledge graph construction for resource collaborative scheduling, existing technologies mostly employ relatively basic processing methods. In the text segmentation stage, the scheduling text is often split based on a fixed number of characters or punctuation marks; knowledge extraction mainly relies on conventional triple extraction patterns to obtain static structures; entity alignment depends on simple string matching; and relation completion is mostly based on graph structure similarity. These technologies can, to a certain extent, complete basic information processing and knowledge graph construction tasks, supporting the basic process of resource scheduling.

[0003] However, existing technologies have several key problems. First, the text segmentation method is crude and easily disrupts the complete scheduling process, breaking the closed loop of "resource allocation - task execution - task completion - resource release" into isolated fragments, resulting in the loss of key time-bound relationships and causing duplicate modeling of the same resource. Second, knowledge extraction and relation completion lack accurate perception of the core elements of scheduling. Conventional triple extraction cannot effectively handle time-sensitive relationships such as "immediate execution" and "delayed start," and time information is only used as a post-processing field, resulting in insufficient temporal accuracy of the extraction results. Relationship completion relies solely on structural similarity, which easily leads to misjudgment of relationships and the generation of erroneous edges that violate scheduling rules such as resource exclusivity and priority. Furthermore, the "complete edges first, then delete them" strategy cannot fundamentally prevent the learning of erroneous patterns. Summary of the Invention

[0004] This application provides a resource collaborative scheduling method that integrates ontology models and large models to solve the aforementioned problems in existing solutions.

[0005] Firstly, this application provides a resource collaborative scheduling method for fusing ontology models and large models, the method comprising:

[0006] Acquire scheduling text data; there is a preset number of labeled scheduling text data; assign time anchors to each candidate event statement in the scheduling text data, and then use the labeled scheduling text data to identify the participating objects in the candidate event statements, and then use the time anchors, participating objects, and action types to divide the scheduling text data into several event blocks to obtain an event block sequence;

[0007] Based on the event block sequence, a dynamic prompt is constructed for each event block; based on the dynamic prompt, a large language model is invoked to perform structured extraction on each event block to obtain original knowledge fragments; source tracing information is attached to the original knowledge fragments to obtain an original knowledge fragment set; the similarity between the entity description vectors corresponding to entities in the original knowledge fragment set is used to perform entity merging and alignment operations; the original knowledge fragment set with completed entity alignment operations is used to generate an initial scheduling graph.

[0008] Based on the preset resource registry, preset scheduling rule table, and initial scheduling graph, a preset resource constraint table is constructed; based on the preset entity relationship template table and the time anchor point difference between node actions in the initial scheduling graph, a candidate relationship set containing node combinations that satisfy the preset resource constraint table is constructed.

[0009] Obtain the predicted latency corresponding to the candidate relationship; calculate the constraint violation factor using the relationship between the candidate relationship, the predicted latency, and the preset resource constraint table; calculate the relationship score of the candidate relationship using the trained resource constraint graph neural network based on the constraint violation factor; and complete the candidate relationship between the node combinations in the initial scheduling graph according to the relationship score, the preset resource constraint table, and the trained resource constraint graph neural network to obtain the complete scheduling graph.

[0010] Based on the complete scheduling diagram, generate corresponding conceptual classes, object attributes, and data attributes; based on the complete scheduling diagram and the preset resource constraint table, generate corresponding conceptual axioms, relational axioms, and scheduling rules with time delay windows, and then unify them into a deployable scheduling domain ontology; deploy the scheduling domain ontology to the resource collaborative scheduling system.

[0011] In one implementation of this application, obtaining scheduling text data and assigning time anchors to each candidate event statement in the scheduling text data specifically includes:

[0012] Collect scheduling text data generated during the operation of the scheduling system covering the entire scheduling cycle; the annotation adopts the sequence annotation method, obtains the entity class annotation data corresponding to a preset number of scheduling text data, and obtains a preset number of annotated scheduling text data;

[0013] Perform text standardization processing on the scheduling text data;

[0014] By using a combination of preset punctuation and preset action words, the standardized scheduling text data is segmented into several candidate event statements.

[0015] When multiple preset action words appear in a candidate event statement, the candidate event statement is further segmented according to the position of the action words.

[0016] Extract time representations from candidate event statements; when the time representation is a specific time, convert it to a standard time; when the time representation is a non-specific time, determine the corresponding standard time based on the preset offset time corresponding to the non-specific time and the standard time corresponding to the previous time representation; when a candidate event statement has a standard time, determine the standard time as the time anchor point; when a candidate event statement does not have a standard time, determine the time anchor point of the current candidate event statement based on the time anchor points of the previous and next candidate event statements.

[0017] In one implementation of this application, the participating objects in candidate event statements are identified using annotated scheduling text data. Then, the scheduling text data is divided into several event blocks using time anchors, participating objects, and action types to obtain an event block sequence, specifically including:

[0018] Using the scheduling text data of the labeled participants, a named entity recognition model is trained to obtain a well-trained named entity recognition model.

[0019] Using a trained named entity recognition model, identify the participating objects in candidate event statements;

[0020] Read the action type from the candidate event statement;

[0021] Based on time anchors, action types, and participating objects, identify whether the candidate event statements corresponding to scheduling text data show changes in the preset time anchor interval, action changes, or participating objects;

[0022] When there is a change in the preset time anchor interval, a change in action, or a change in the participating object, the candidate event statement is divided into two event blocks, and then the event block sequence is obtained.

[0023] In one implementation of this application, dynamic prompts are constructed for each event block based on the event block sequence; based on the dynamic prompts, a large language model is invoked to perform structured extraction on each event block to obtain original knowledge fragments; source tracing information is then appended to the original knowledge fragments to obtain a set of original knowledge fragments, specifically including:

[0024] Based on the event block sequence, dynamic prompts are constructed for the content according to the original text of the current event block, the summary of the previous event block, the summary of the next event block, and the preset field output format requirements. The preset field output format requirements include: header entity, relation, tail entity, time anchor, relation delay, extraction confidence, and evidence fragment.

[0025] Based on dynamic prompts, a large language model is invoked to perform structured extraction on each event block to obtain raw knowledge fragments; among which, the raw knowledge fragments include at least: head entity, relation, tail entity, time anchor, relation delay, extraction confidence, and evidence fragments.

[0026] Preprocess the original knowledge fragments and remove those that do not meet the preset requirements;

[0027] Obtain the source tracing information of each original knowledge fragment, attach the source tracing information to the original knowledge fragment, and obtain the original knowledge fragment set; wherein, the source tracing information includes at least: scheduling text number, event block number, and original text position of evidence fragment.

[0028] In one implementation of this application, an entity merging and alignment operation is performed based on the similarity between the entity description vectors corresponding to entities in the original knowledge fragment set; an initial scheduling graph is generated using the original knowledge fragment set after the entity alignment operation, specifically including:

[0029] Standardize and unify the names of all entities in the original set of knowledge fragments;

[0030] An entity description vector is generated for the entity after standardized and unified processing; the entity description vector is jointly encoded by the entity name, the evidence fragment in which the entity is located, the name of the adjacent relationship, and the entity type;

[0031] Based on the preset similarity relationship, candidate entity pairs are generated from all entities;

[0032] Calculate the similarity between the entity description vectors of candidate entity pairs; where the similarity includes: name similarity, context similarity, and type consistency; when the similarity meets the preset merging condition value, perform the candidate entity pair merging and alignment operation; and switch the merged entity name to the preset standard name;

[0033] Obtain the original knowledge fragment set after entity alignment operation, and use the preset standard data dictionary to convert the entity names in the original knowledge fragment set into standard names and the relation names in the original knowledge fragment set into standard relation names;

[0034] Nodes of the initial scheduling graph are generated based on the entities in the original knowledge fragment set, and edges of the initial scheduling graph are generated based on the relationships in the original knowledge fragment set.

[0035] In one implementation of this application, a preset resource constraint table is constructed based on a preset resource registry, a preset scheduling rule table, and an initial scheduling graph; a candidate relationship set containing node combinations that satisfy the preset resource constraint table is constructed based on a preset entity relationship template table and the time anchor point difference between node actions in the initial scheduling graph. Specifically, this set includes:

[0036] Based on the preset resource registry, preset scheduling rule table, and initial scheduling graph, a preset resource constraint table is constructed; wherein, the preset resource constraint table includes at least: resource exclusivity constraint, priority constraint, and latency limit constraint;

[0037] Construct a node feature vector for each node in the initial scheduling graph; wherein the node feature vector includes at least: standard entity name vector, entity type code, entity reliability, node degree, and adjacency frequency histogram;

[0038] Construct an edge feature vector for each edge in the initial scheduling graph; wherein the edge feature vector includes at least: relation name encoding, relation delay bucket encoding, extraction confidence, and time direction label;

[0039] Retrieve a preset entity relationship template table that specifies the head and tail entity types that are allowed to be joined for each standard relationship;

[0040] When any pair of nodes satisfies at least one rule in the preset entity relationship template table, and the time anchor difference is less than the maximum time window of the candidate relationship, and the pair of nodes is not directly connected in the initial scheduling graph, and there is a connection path of preset length or the number of co-occurrences in adjacent scheduling text data is greater than the preset number, it is determined as a candidate relationship, and then a set of candidate relationships is constructed.

[0041] In one implementation of this application, before calculating the relationship score of candidate relationships between node combinations using a trained resource constraint graph neural network, the method further includes:

[0042] The training scheduling graph is divided into a training edge set, a validation edge set, and a test edge set.

[0043] The real edges in the training edge set are used as candidate relations for positive samples; the node pairs that match the type but do not exist in the scheduling graph are extracted from the candidate relation set corresponding to the training scheduling graph as candidate relations for negative samples.

[0044] A resource-constrained graph neural network is constructed, consisting of two relation-aware message passing layers and one relation scoring head. Each relation-aware message passing layer targets the central node and aggregates the features of its neighboring nodes and edges. The weights of neighboring messages are determined by the features of the central node, the features of neighboring nodes, the relation name encoding, and the relation delay binning. The output of the second layer serves as the final representation of the node.

[0045] The node feature vectors and edge feature vectors of the training scheduling graph are input into the resource constraint graph neural network, and the final representation vectors of all nodes are output through a two-layer relation-aware message passing layer.

[0046] Through the formula:

[0047] The computation node u and node v belong to the candidate relationship. Relationship rating ;

[0048] in, Represents the Sigmoid function; Representing relations The corresponding rating parameter vector, express Transpose of; This indicates vector concatenation; Represents a node With nodes The time difference encoding vector between them; Indicates candidate relationship The corresponding constraint violation factor ranges from 0 to 1. This represents the final representation vector of node u. This represents the final representation vector of node v;

[0049] Relationship between node u and node v, and candidate relationships. Input a fully connected network, output the predicted latency;

[0050] When a candidate relationship does not meet the resource exclusivity constraint or priority constraint in the preset resource constraint table, Set to 1 to score the initial relationship. The value is reduced to 0; when a candidate relationship meets the resource exclusivity constraint and priority constraint in the preset resource constraint table but the predicted latency is higher than the latency upper limit constraint in the preset resource constraint table, it will be... Set within the preset soft penalty value range;

[0051] In the training process of the resource-constrained graph neural network, joint loss is used to train the resource-constrained graph neural network; the joint loss includes: relation existence loss, relation type classification loss, time delay regression loss and constraint penalty loss.

[0052] In one implementation of this application, the predicted latency corresponding to the candidate relationships between node combinations is obtained; the constraint violation factor is calculated using the relationship between the candidate relationships, the predicted latency, and the preset resource constraint table; based on the constraint violation factor, a relationship score of the candidate relationships between node combinations is calculated using a trained resource constraint graph neural network, specifically including:

[0053] Input the node combination and candidate relationship into the fully connected network, and output the predicted latency;

[0054] When a candidate relationship does not meet the resource exclusive constraint or priority constraint in the preset resource constraint table, the constraint violation factor is set to 1; when a candidate relationship meets the resource exclusive constraint and priority constraint in the preset resource constraint table but the prediction latency is higher than the latency upper limit constraint in the preset resource constraint table, the constraint violation factor is set to the preset soft penalty value range.

[0055] The node feature vector of the node combination and the edge feature vector of the candidate relationship are input into the resource constraint graph neural network, and the final representation vector of the node is output through a 2-layer relationship-aware message passing layer.

[0056] By substituting the constraint violation factor and the final representation vector into the preset relationship scoring formula, the relationship score of the candidate relationship between node combinations is calculated.

[0057] In one implementation of this application, candidate relationships between node combinations in the initial scheduling graph are completed based on relationship scores, a preset resource constraint table, and a trained resource constraint graph neural network to obtain the completed scheduling graph. Specifically, this includes:

[0058] Add candidate relations whose relation scores are greater than the preset edge-filling threshold to the edge-filling list;

[0059] Verify whether the candidate relationships in the list of edges to be filled meet the resource exclusive constraints and priority constraints in the preset resource constraint table. If they do not meet the resource exclusive constraints and priority constraints, remove them from the list of edges to be filled.

[0060] Verify whether the candidate relations in the list of edges to be supplemented meet the time limit constraint in the preset resource constraint table, whether there is a preset high confidence relation conflict, and whether they form duplicate semantics with the edges in the same time window. If they only do not meet the time limit constraint and the difference is less than the preset difference threshold, reduce the confidence of the corresponding edge; otherwise, remove it from the list of edges to be supplemented.

[0061] Add the edges from the list of edges to be supplemented to the initial scheduling graph to obtain the completed scheduling graph; where the edge confidence is calculated by combining the relationship score, the relationship classification probability and the corresponding entity reliability.

[0062] After obtaining the completed scheduling graph, the number of newly added edges and the average confidence of newly added edges are counted. If the number of newly added edges and the average confidence of newly added edges meet the preset stopping condition for two consecutive rounds, the current completed scheduling graph is taken as the complete scheduling graph.

[0063] If the preset stopping condition is not met, the completed scheduling graph will be input into the trained resource constraint graph neural network again to obtain the completed scheduling graph, until the preset stopping condition is met and the complete scheduling graph is obtained.

[0064] In one implementation of this application, corresponding conceptual classes, object attributes, and data attributes are generated based on the complete scheduling graph; corresponding conceptual axioms, relational axioms, and scheduling rules with delay windows are generated based on the complete scheduling graph and a preset resource constraint table, and then unified into a deployable scheduling domain ontology, specifically including:

[0065] Generate concept classes based on node type labels, entity name patterns, and relationship contexts in the complete scheduling graph;

[0066] Generate hierarchical concepts based on the pre-defined resource registry and the corresponding name hierarchy words of the node names;

[0067] Data attributes are generated based on the edge attributes and source tracing information in the complete scheduling graph; the data attributes include at least: relationship delay in seconds, edge confidence, action time, source scheduling text number, source event block number, and whether the edge is completed.

[0068] Generate conceptual axioms and relational axioms based on the complete scheduling diagram and the preset resource constraint table;

[0069] Obtain the preset high-frequency path pattern from the complete scheduling graph and generate scheduling rules with a time delay window.

[0070] As can be seen from the above technical solutions, this application has the following advantages:

[0071] This method completely solves the problem of coarse text segmentation in existing methods by assigning time anchors to candidate event statements and dividing event blocks based on participating objects and action types. Compared to traditional methods that easily disrupt the closed loop of "resource allocation - task execution - task completion - resource release," event block division uses complete scheduling logic as a unit, ensuring clear and complete time binding relationships within each event block and avoiding the loss of key timing information. Simultaneously, the same resource only needs to be modeled once within a complete scheduling cycle, effectively preventing resource waste and data redundancy caused by repeated modeling. This makes the structured processing of scheduling text more aligned with actual business processes, laying a precise data foundation for subsequent knowledge extraction and scheduling graph construction.

[0072] In the knowledge extraction stage, dynamic prompts combined with a large language model accurately capture time-sensitive relationships such as "immediate execution" and "delayed start," integrating time information as a core element into the extraction process rather than a simple post-processing field, significantly improving the temporal accuracy of the extraction results. The entity merging and alignment operation calculates the similarity of entity description vectors, achieving accurate matching of the same entity under different descriptions, further ensuring the consistency of knowledge fragments. In the relation completion stage, the inefficient traditional strategy of "completing edges first and then deleting them" is abandoned. Instead, a resource constraint table is first constructed based on a preset resource registry and scheduling rule table, and then a candidate relation set is generated by combining time anchor point differences, reducing the generation of erroneous edges that violate scheduling rules from the source. By calculating relation scores through constraint violation factors and resource constraint graph neural networks, reasonable relations that conform to rules such as resource exclusivity and priority can be intelligently filtered, significantly reducing the relation misjudgment rate and constructing an initial scheduling graph that is more in line with actual scheduling scenarios.

[0073] The resulting deployable scheduling ontology, generated by this method, integrates conceptual classes, object attributes, data attributes, conceptual axioms, relational axioms, and scheduling rules with time-delay windows, achieving a systematic and standardized accumulation of scheduling knowledge. Compared to traditional scheduling systems that rely on fragmented rules and experience, this scheduling ontology provides unified and precise knowledge support for resource collaborative scheduling systems. In practical deployments, the system can quickly understand scheduling needs, determine resource status, and execute reasonable scheduling decisions based on the ontology, significantly improving the automation and intelligence of scheduling. Furthermore, the ontology's scalability allows it to adapt to scheduling scenarios of different industries and scales. As business needs change, the scheduling system can be rapidly iterated and optimized by updating the rules and attributes in the ontology, providing long-term and stable technical support for enterprise resource collaborative scheduling. Attached Figure Description

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

[0075] Figure 1 This is a flowchart of a resource collaborative scheduling method for fusing ontology models and large models, provided in an embodiment of this application.

[0076] Figure 2 This is a schematic diagram of the time anchor point allocation of candidate event statements and the event block division result based on time interval and action type provided in an embodiment of this application.

[0077] Figure 3 This is a schematic diagram showing the time window for two tasks to occupy the exclusive resource and their conflict area, provided in an embodiment of this application.

[0078] Figure 4 This is a resource constraint graph neural network relationship score distribution graph provided in an embodiment of this application.

[0079] Figure 5 This is a conceptual class hierarchy diagram provided in the embodiments of this application. Detailed Implementation

[0080] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0081] Those skilled in the art should understand that the embodiments described below are merely preferred embodiments of this disclosure and do not imply that this disclosure can only be implemented through these preferred embodiments. These preferred embodiments are merely used to explain the technical principles of this disclosure and are not intended to limit the scope of protection of this disclosure. Based on the preferred embodiments provided by this disclosure, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of this disclosure.

[0082] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0083] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0084] The embodiment provides a resource collaborative scheduling method that integrates ontology models and large models, such as... Figure 1 As shown in the embodiments of this application, the method mainly includes the following steps:

[0085] Step 110: Obtain scheduling text data; assign time anchors to each candidate event statement in the scheduling text data, and then use the labeled scheduling text data to identify the participating objects in the candidate event statements. Then, using the time anchors, participating objects, and action types, divide the scheduling text data into several event blocks to obtain an event block sequence.

[0086] Among them, there is a preset number of labeled scheduling text data.

[0087] In some embodiments, obtaining scheduling text data specifically includes:

[0088] Raw scheduling text data is collected for knowledge extraction and model fine-tuning. The collection targets are various text records generated during the operation of the scheduling system, specifically including scheduling logs, work order records, operation and maintenance notes, alarm handling records, and combinations of these records. This text originates from a resource collaborative scheduling system in a real production environment, covering typical scheduling stages such as computing resource allocation, task execution status tracking, resource release and reclamation, and anomaly alarms and handling. During collection, it is necessary to ensure that the time span of the text is sufficient to cover the complete scheduling cycle, for example, from the arrival of resource requests, resource allocation, task execution to resource release, so that scheduling knowledge with temporal relationships can be extracted subsequently.

[0089] The collected raw scheduling text set is denoted as the total scheduling text to be processed. Each scheduling text corresponds to an independent record. The total number of scheduling texts depends on the actual system scale and should usually include several thousand or more to support the stability of subsequent statistical analysis.

[0090] The collected raw scheduling text needs to be cleaned and standardized to eliminate format inconsistencies caused by manual input or system export. Cleaning operations include removing meaningless duplicate spaces, standardizing Chinese and English punctuation, standardizing full-width and half-width characters, and correcting obvious encoding errors. The cleaned text retains key information such as the original time string, task number, and resource number, without converting the time expression or changing the original sentence order.

[0091] After cleaning, a portion of the scheduling text needs to be manually annotated. Annotation uses sequence labeling, such as the BIO annotation system, where B represents the beginning of an entity, I represents the interior of an entity, and O represents non-entity parts. The entity categories to be annotated must include at least four types: resource name, task name, node name, and user name.

[0092] Resource names encompass the specific identifiers of hardware or virtual resources such as GPUs, CPUs, storage volumes, and network interfaces; task names include task numbers, job names, and work order numbers; node names refer to the identifiers of physical machine or container nodes; and user names refer to the user or business account that submitted the scheduling request.

[0093] The input data is defined as the set of scheduling texts corresponding to the scheduling text data. ,in, This represents all the scheduling texts to be processed. Indicates the first Dispatch text, This indicates the number of scheduling texts. Scheduling texts can come from scheduling logs, work order records, operation and maintenance notes, alarm handling records, or a combination thereof.

[0094] In some embodiments, using labeled scheduling text data, the participating objects in candidate event statements are identified, and then the scheduling text data is divided into several event blocks using time anchors, participating objects, and action types to obtain an event block sequence, specifically including:

[0095] With the first Dispatch text For input, for the th Dispatch text Perform text standardization processing.

[0096] In one implementation, text standardization processing includes: removing meaningless duplicate spaces, standardizing Chinese and English parentheses, standardizing full-width and half-width punctuation, standardizing resource number connectors, retaining the original time string, retaining the task number, and retaining the resource number.

[0097] The first Dispatch text Break it down into candidate event statements, specifically...

[0098] The granularity of candidate event statements is determined by a combination of "punctuation + action words". The action word vocabulary can be pre-maintained as a fixed dictionary. Action words include at least: allocate, bind, start, execute, pause, resume, complete, release, reclaim, migrate, preempt, rollback, alarm, and deactivate.

[0099] Furthermore, when multiple action words appear in a long sentence, it is further segmented according to the position of the action words;

[0100] In one embodiment, for example, if the original sentence is: "10:03 allocate GPU-01 to task A and start task A at 10:04", then the segmentation result should be two candidate event statements, instead of retaining one long sentence. The segmentation result is:

[0101] Candidate event statement 1: 10:03 Assign GPU-01 to task A;

[0102] Candidate event statement 2: and start task A at 10:04.

[0103] Extract explicit and relative time representations from all candidate event statements.

[0104] Explicit time expressions are primarily identified using regular expression matching, with matching formats including “YYYY-MM-DD HH:MM:SS”, “HH:MM:SS”, “HH:MM”, ​​“X month X day X hour X minute”, etc.

[0105] Relative time expressions are identified through a time word vocabulary, which includes at least "immediately", "subsequently", "after 30 seconds", "within 5 minutes", "after completion", and "after timeout".

[0106] For example, for the text fragments "start training in 30 seconds" and "release immediately after completion", the time word vocabulary matches "30 seconds later" (offset +30 seconds), "after completion" (depending on the completion time of the previous event), and "immediately" (offset 0 seconds).

[0107] In the specific implementation, if the candidate event statement contains the complete date and time (hours, minutes, and seconds), it is directly converted to standard time; if it only contains hours, minutes, and seconds, it is padded to the date to which the current scheduling record belongs; if it only contains relative time, its time offset and offset direction are recorded.

[0108] In one embodiment, as an example, explicit time: "2026-04-06 10:03:15" → standard timestamp 2026-04-06 10:03:15; hours, minutes, and seconds only: "10:03:15", if the date of the scheduling record is 2026-04-06 → padded to 2026-04-06 10:03:15; relative time: "30 seconds later", the previous event anchor point is 2026-04-06 10:03:15 → current anchor point 2026-04-06 10:03:45.

[0109] Assign a time anchor point to each candidate event statement, denoted as . , Indicates the first The first dispatch text The unified time coordinates for each candidate event statement can be in the form of a second-level timestamp.

[0110] In the specific implementation, if the current candidate event statement contains an explicit time expression, the explicit time expression is directly converted into a time anchor point; if the current candidate event statement only contains a relative time expression, the current time anchor point is obtained by accumulating the offset based on the previous candidate event statement with a determined time anchor point; if the current candidate event statement has neither an explicit time expression nor a relative time expression, but is located between two candidate event statements with known time anchor points, the intermediate time anchor point is obtained by linear interpolation; if all candidate event statements in the current scheduling text have no time expression, the time of entry into the scheduling text is used as the time anchor point of the first candidate event statement, and the subsequent candidate event statements are extended by a fixed micro-hour difference according to the order of the candidate event statements. The fixed micro-hour difference can be 3 to 10 seconds.

[0111] For each candidate event statement, identify the action type and participating objects, specifically...

[0112] Action types are identified using a combination of "action word vocabulary matching and syntactic dependency correction," and the main participating objects include at least one or more of the following: resource objects, task objects, and alarm objects.

[0113] In one implementation, the named entity recognition model can first identify the resource name, task name, node name, and user name, and then determine "who performed what action on whom" through syntactic dependency analysis. For example, from "10:03 allocate GPU-01 to task A", the resource object is identified as GPU-01, the task object is task A, and the action type is allocation. The named entity recognition model can be obtained by fine-tuning an open-source pre-trained language model (such as BERT, RoBERTa, Chinese BERT-wwm, etc.) with a small amount of labeled scheduling text corpus.

[0114] Candidate event statements are divided into event blocks based on changes in time anchor points, action types, and main participating objects. , Indicates the first The first dispatch text One event block.

[0115] In specific implementation, if the time interval between the current candidate event statement and the previous candidate event statement is greater than the preset time segmentation threshold, the event block is segmented before the current candidate event statement; if the action type changes from "resource allocation" to another type of action such as "resource release" or "task completion", and the participating object changes, the event block is also segmented at the current position; if the time interval is small, but the main resource object changes, for example, from GPU-01 to GPU-02, segmentation is also performed.

[0116] In practical implementation, the time segmentation threshold can be twice the median response time of the scheduling task in history. In engineering implementation, it can also be directly set to 60 seconds or 120 seconds.

[0117] In one embodiment, for example, the sequence of candidate event statements is as follows:

[0118] Statement 1: 10:03:15 Allocate GPU-01 to task A;

[0119] Statement 2: Start Task A at 10:03:45;

[0120] Statement 3: 10:04:00 Task A completed;

[0121] Statement 4: 10:05:20 Release GPU-01;

[0122] The time intervals are 30 seconds, 15 seconds, and 80 seconds. If the time segmentation threshold is 60 seconds, then the interval between the 3rd and 4th events is 80 seconds (which is greater than 60 seconds), so the event is segmented before the 4th event to obtain the event block.

[0123] Event block 1: Statements 1, 2, and 3;

[0124] Event block 2: Statement 4.

[0125] like Figure 2 As shown in one embodiment, the time anchor point allocation of candidate event statements and the event block partitioning results based on time interval and action type are demonstrated, proving that the present technology can cluster discrete scheduling text statements into complete event blocks according to temporal continuity and scheduling semantics, avoiding the fragmentation of cross-sentence constraint information. In the figure, the horizontal axis represents the time offset relative to the start time (unit: seconds), and the vertical axis represents the schematic position of the event statement (unitless). Different colored backgrounds distinguish two event blocks: event block 1 contains statements from "received task A request" to "task A completed," and event block 2 contains "release GPU-01," reflecting the effectiveness of time anchor point completion and event block boundary segmentation.

[0126] Step 120: Based on the event block sequence, construct dynamic prompts for each event block; based on the dynamic prompts, call the large language model to perform structured extraction on each event block to obtain original knowledge fragments, attach source tracing information to the original knowledge fragments to obtain an original knowledge fragment set; perform entity merging and alignment operations on the similarity between the entity description vectors corresponding to entities in the original knowledge fragment set; use the original knowledge fragment set with completed entity alignment operations to generate an initial scheduling graph.

[0127] Based on the event block sequence, a dynamic prompt is constructed for each event block, which can be specifically:

[0128] Conventional triple extraction can only obtain "head entity-relation-tail entity", and cannot distinguish time-sensitive relations such as "immediate execution", "delayed execution", and "timeout release". This application incorporates the original text of the event block, the summary of adjacent event blocks, and the time context into the prompt content, enabling the large language model to directly output the original knowledge fragments with time attributes and evidence fragments. The specific steps are as follows:

[0129] With event block sequence For input, a dynamic hint is constructed for each event block. Specifically, the original text of the current event block, the summary of the previous event block (if it exists), the summary of the next event block (if it exists), and the output format requirements are concatenated into a hint string.

[0130] Dynamic prompts should include at least four types of content: the original text of the current event block, the summary of the previous event block, the summary of the next event block, and the field output format requirements;

[0131] The field output format must include at least: head entity, relation, tail entity, action time, relation delay, extraction confidence, and evidence fragment.

[0132] In one embodiment, as an example, the original text of an event block is "10:03:15 Allocate GPU-01 to task A", the digest of the previous event block is "10:03:00 Received request from task A", and the digest of the next event block is "10:03:45 Start task A". The constructed dynamic prompt is as follows:

[0133] Please extract knowledge from the following scheduling text and output it in JSON format, with fields including: head (head entity), relation (relation), tail (tail entity), action_time (action time, format YYYY-MM-DD HH:MM:SS), delay_sec (relation delay, in seconds), confidence (0~1), and evidence (evidence fragment). Current event block summary: 10:03:15 Allocate GPU-01 to task A; Previous event block summary: 10:03:00 Received request from task A; Next event block summary: 10:03:45 Start task A.

[0134] The large language model is invoked to perform structured extraction on each event block. The output of the large language model is preferably in a fixed key-value format, such as a list format or JSON format, so that subsequent programs can parse it directly.

[0135] If the large language model outputs multiple relations, they are recorded one by one. If a single text contains a compound relation, such as "Release GPU-01 and reclaim container instance C immediately after task A is completed," it is split into two original knowledge fragments because it contains two actions: releasing GPU-01 and reclaiming container instance C, and shares the premise "task A is completed." Therefore, it should be split into:

[0136] Fragment 1: Head entity = Task A completion event, Relationship = Release, Tail entity = GPU-01;

[0137] Fragment 2: Head entity = Task A completion event, Relationship = Recycling, Tail entity = Container instance C.

[0138] The output of the large language model is parsed into raw knowledge fragments. Each raw knowledge fragment contains at least the head entity name, relation name, tail entity name, action time anchor, relation delay, extraction confidence, and evidence fragment.

[0139] All original knowledge fragments are compiled into a set of original knowledge fragments. , This represents the original set of knowledge fragments before cross-text entity alignment was performed.

[0140] In practical implementation, if the large language model has directly output the relation latency, it is directly written into the original knowledge fragment; if it only outputs descriptions such as "immediately", "later", and "after timeout", it is converted into a second-level value according to the time word mapping table. For example, "immediately" is mapped to a fixed representative value of 1 second in the range of 0 to 3 seconds, "within the next 30 seconds" is mapped to 30 seconds, and "within 5 minutes" is mapped to 300 seconds. If the original knowledge fragment spans two adjacent event blocks, the difference between the starting time anchor points of the two event blocks can also be directly used as the relation latency.

[0141] The relation names in the original knowledge fragments are standardized, specifically...

[0142] Relation name normalization is accomplished using a standard relation dictionary, which includes at least the following: allocation, execution, completion, release, reclamation, preemption, migration, dependency, conflict, priority over, alert over, and clear alert.

[0143] In the specific implementation, "assign to", "bind to", and "issue to" are uniformly mapped to "allocate", and "release after completion" and "reclaim resources" are uniformly mapped to "release" or "reclaim". If the current relationship naturally contains time semantics, the relationship name is not split separately. Instead, the time semantics are stored in the relationship delay field, thereby avoiding the same semantic relationship from being split into too many relationship types due to time differences.

[0144] Remove obviously incomplete or obviously erroneous original knowledge fragments. The removal conditions include at least: missing head entity, missing tail entity, relation name not in the standard relation dictionary, extraction confidence score below a preset threshold (e.g., 0.7), and evidence fragment is empty and cannot be traced back to the original text.

[0145] It should be noted that if the original knowledge fragment is missing only the relational delay but its action time anchor and associated event block can be located, it will not be directly removed, but the relational delay will be supplemented in subsequent steps based on the time anchor.

[0146] The filtered original knowledge fragments are written back to the event block and the original scheduling text number, retaining the source tracing information. The source tracing information includes at least: scheduling text number, event block number, and the original text position of the evidence fragment. Based on this, the source text of each relation can be traced back when generating subsequent ontology rules.

[0147] In one embodiment, for example, the original text of the current event block is "2026-04-06 10:03:15 Allocate GPU-01 to task A", and the summary of the next event block is "Start task A in 30 seconds". The dynamic prompt requests the output of structured fields. The large language model may output "Head entity = GPU-01, relation = allocation, tail entity = task A, action time = 2026-04-06 10:03:15, relation latency = 30 seconds, extraction confidence = 0.92, evidence fragment = Allocate GPU-01 to task A; then start task A within 30 seconds". This output is then parsed and written into the original knowledge fragment set. .

[0148] Based on this, one or more original knowledge fragments that have passed the screening are obtained, and these fragments are written into the original knowledge fragment set. Each fragment is accompanied by source tracing information (scheduling text number, event block number, and original location of the evidence fragment).

[0149] It should be noted that "execute immediately after allocation" and "release a few minutes after allocation" are not equivalent in scheduling semantics. This application does not extract static relations first and then fill in the time field, but directly uses the time context as part of the extraction input, thereby improving the extraction accuracy of time-sensitive relations and providing a more reliable time delay prior for subsequent relation completion.

[0150] The specific steps to generate the initial scheduling graph are as follows:

[0151] For the original knowledge fragment set All entity names in the file undergo standardization processing. Specifically, the standardization processing includes: removing meaningless prefixes and suffixes, standardizing capitalization, standardizing connectors, standardizing resource number padding rules, and standardizing task number format.

[0152] For example, “GPU1”, “GPU-1”, and “GPU_01” are uniformly converted to “GPU-01”, and “Task A” and “Job A” retain the original literal values ​​while extracting the candidate task identifier “A”.

[0153] For each entity, an entity description vector is generated. The entity description vector is jointly encoded by the entity name, the evidence fragment in which the entity is located, the name of the adjacent relationship, and the entity type.

[0154] The entity type can be given by the named entity recognition result, and includes at least one of the following: computing resources, storage resources, network resources, task entities, alarm entities, and scheduling action objects.

[0155] In practical implementation, "entity name + evidence fragment" can be input into a lightweight text vector model to obtain a fixed-length vector, which is then concatenated with the entity type one-hot encoding to form an entity description vector.

[0156] In one embodiment, as an example, an entity description vector is as follows:

[0157] Entity name: "GPU-01", Evidence fragment: "Assign GPU-01 to task A", Adjacency relationship: Assign, Release, Entity type: Computing resource;

[0158] Inputting "GPU-01 is assigned to task A" into a lightweight text vector model (such as Sentence-BERT, TF-IDF+word embedding average, or FastText) yields a 128-dimensional vector. One-hot encoding of entity types (assuming there are 5 types in total) yields a 5-dimensional vector. After concatenation, a 133-dimensional entity description vector is obtained.

[0159] Candidate entity pairs are generated and their similarity is calculated. Candidate entity pairs are preferentially generated from the following objects: entity pairs with the same resource type and similar numbers, entity pairs with the same task type and similar names, and entity pairs that co-occur repeatedly in adjacent scheduling texts.

[0160] In practical implementation, at least three types of similarity are calculated for each candidate entity pair: name similarity, context similarity, and type consistency; among them,

[0161] Name similarity can be calculated using edit distance or number matching; context similarity can be calculated using the cosine similarity of entity description vectors; type consistency is determined using Boolean values.

[0162] Entity merging is performed only when both name similarity and context similarity exceed preset thresholds and type consistency is achieved. Preferably, the name similarity threshold can be 0.8 and the context similarity threshold can be 0.85.

[0163] In one embodiment, for example, the candidate entity pair is: "GPU-01" and "GPU Card No. 1";

[0164] Name similarity: The edit distance after normalization is 0.83;

[0165] Context similarity: The cosine similarity of the entity description vectors is 0.91;

[0166] Type consistency: All are computing resources → True;

[0167] Thresholds: Name similarity ≥ 0.8, context similarity ≥ 0.85, both must be met and the types must be consistent → Execute merge.

[0168] For each group of entities identified as the same object, select a standard entity name. The standard entity name should preferably be the official name in the resource registry or task registry. If there is no official name, use the name that appears most frequently and contains the most complete type word and number.

[0169] Furthermore, once the standard entity names are determined, the original set of knowledge fragments will be... All old entity names in the database will be replaced with standard entity names. For example, if the official name in the resource registry is "GPU-01", then "GPU-01" will be used. All "GPU Card No. 1" and "GPU_01" in the original knowledge fragment will be replaced with "GPU-01".

[0170] The entity reliability is calculated for each standard entity. The entity reliability is obtained by averaging the confidence scores of all original knowledge fragments corresponding to that standard entity.

[0171] The higher the entity reliability, the more reliably the standard entity can be identified across multiple scheduling texts.

[0172] In one embodiment, for example, the standard entity "GPU-01" corresponds to 3 original knowledge fragments with confidence levels of 0.92, 0.88, and 0.96, respectively. Therefore, the entity reliability is (0.92 + 0.88 + 0.96) / 3 = 0.92.

[0173] An initial scheduling graph is generated based on the original knowledge fragments after entity alignment. ,in,

[0174] Represents the initial scheduling graph. This represents the initial set of nodes, where each node corresponds to a standard entity. This represents the initial set of edges, with each edge corresponding to a standard relation. Each edge must contain at least the relation name, relation delay, action time anchor, extraction confidence, and source tracing information.

[0175] In one embodiment, the name similarity between "GPU-01" and "GPU Card No. 1" is 0.83, and the context similarity is 0.91. Both are identified as computing resources, so it is determined that these two entities should be merged. If the official name in the resource registry is "GPU-01", then "GPU-01" is adopted as the standard entity name, and "GPU Card No. 1" in all original knowledge fragments is uniformly replaced with "GPU-01".

[0176] In one embodiment, the initial scheduling graph nodes GPU-01, Task A, Task A Completion Event Initial scheduling diagram edge Possible:

[0177] GPU-01--(Assignment, Latency=30s, Time=10:03:15, Confidence=0.92)-->Task A;

[0178] Task A -- (Completed, Delay = 45s, Time = 10:04:00, Confidence = 0.95) --> Task A completion event.

[0179] Step 130: Construct a preset resource constraint table based on the preset resource registry, preset scheduling rule table, and initial scheduling graph; construct a candidate relationship set containing node combinations that satisfy the preset resource constraint table based on the time anchor point difference between node actions in the preset entity relationship template table and the initial scheduling graph.

[0180] Specifically, a preset resource constraint table is constructed based on the preset resource registry, the preset scheduling rule table, and the initial scheduling graph, as follows:

[0181] Read the resource registry, scheduling rule table, and initial scheduling graph. ,in,

[0182] The resource registry should at least include the resource name, resource type, capacity, and whether it is exclusive; the scheduling rule table should at least include the task priority, resource allocation rules, default release time limit, and abnormal rollback rules.

[0183] In practical implementation, if a complete scheduling rule table does not exist in the system, empirical rules can be obtained from the statistics of historical scheduling texts. For example, if a certain type of computing resource is usually released within 30 seconds after the task is completed, then 30 seconds can be used as the empirical release time limit.

[0184] Construct resource exclusivity constraint records, specifically...

[0185] For resources with a capacity of 1 or marked as exclusive, if two overlapping "allocation" relationships occur for the same resource in time, a resource exclusive conflict is identified.

[0186] In the specific implementation, a resource occupation time window is first established for each "allocation" relationship. The starting point of the resource occupation time window is the action time anchor point of the "allocation" relationship, and the ending point is preferentially taken as the action time anchor point of the most recent subsequent "release" relationship corresponding to the same resource. If no subsequent "release" relationship is found, the action time anchor point of the current "allocation" relationship is taken plus the default occupation time. The default occupation time can be taken as the standard occupation time of this type of resource in the scheduling rule table. If it is still missing, the 95th percentile time of the historical similar relationship is used.

[0187] Furthermore, if two resource occupancy time windows overlap, then in the resource constraint table... Write a resource exclusive constraint record into it.

[0188] Construct priority constraint records, specifically,

[0189] Priority constraints are used to express that higher priority tasks should obtain resources, execute, or resume before lower priority tasks.

[0190] In practice, priority information is first read from the task priority field in the scheduling rule table; if the scheduling rule table is missing, priority clues are extracted from expressions such as "high priority," "urgent," "preemptive," and "delay low priority tasks" in the scheduling text; for two tasks competing for the same resource within the same time window, if task A has a higher priority than task B, then priority information is retrieved from the resource constraint table. Write a constraint record stating that "Task A takes precedence over Task B".

[0191] Construct a delay upper limit constraint record. The delay upper limit constraint is used to express the maximum allowed duration of a certain type of relationship, such as "start within 60 seconds after allocation" or "release within 30 seconds after completion".

[0192] In practice, the latency limit is preferentially taken from the explicit value in the scheduling rule table; if the scheduling rule table does not provide an explicit value, then it is taken from the initial scheduling graph. We collect historical latency samples of similar real relationships and take the 95th percentile value as the empirical latency upper limit, thereby avoiding the upper limit being too large due to a small number of extreme abnormal latency.

[0193] Organize all constraint records into a resource constraint table. Resource constraint table Each record in the resource constraint table must contain at least: constraint type, constraint subject, constraint object, applicable relation name, start time window, end time window, and allow or prohibit conditions. They will then directly participate in candidate edge selection and relationship scoring.

[0194] In one embodiment, GPU-01 is marked as an exclusive resource, and the initial scheduling graph... There are two relationships in the resource constraint table: "10:03 allocate GPU-01 to task A, 10:06 release GPU-01" and "10:04 allocate GPU-01 to task B". Therefore, the occupancy window from 10:03 to 10:06 overlaps with the window starting at 10:04. Write a resource exclusive constraint record stating that "GPU-01 cannot be allocated to both task A and task B simultaneously within this time window".

[0195] The default resource constraint table is shown below:

[0196]

[0197] It should be noted that the key point of this application is not to delete edges uniformly after graph completion, but to convert resource constraints into computable constraint records before graph completion. This is because if edges are added first and then deleted, the graph neural network will still learn towards incorrect patterns during the training phase. By constructing the resource constraint table in advance, the problem can be solved. This allows the completion process to avoid obviously unreasonable relationships from the very beginning.

[0198] In one embodiment, such as Figure 3 As shown, taking GPU-01 as an example, this diagram illustrates the time windows and conflict areas of two tasks occupying the exclusive resource. The resource constraint table captures resource exclusive conflicts, providing a hard constraint basis for subsequent relationship completion. The horizontal axis in the diagram represents the time axis (unit: seconds, relative to the baseline time 10:03:00), and the vertical axis represents the task name (no unit). The orange and red horizontal bars represent the occupation intervals of task A and task B, respectively. The semi-transparent area in the middle indicates the exclusive conflict caused by the overlap of the two windows, demonstrating the detection logic of resource exclusive constraints.

[0199] Furthermore, relation completion should not be performed blindly between all pairs of nodes; otherwise, the number of candidates will be too large and the probability of incorrect edge completion will be high. This application first generates candidate relations based on node type, temporal proximity, and existing graph structure, and then provides node features and edge features for the resource-constrained graph neural network. The specific steps are as follows:

[0200] For the initial scheduling graph Each node in the algorithm constructs a node feature vector, which includes at least: standard entity name vector, entity type encoding, entity reliability, node degree, and adjacency frequency histogram.

[0201] In the specific implementation, the standard entity name vector can be obtained from a lightweight text vector model; the entity type encoding adopts one-hot encoding; the node degree is the number of edges connected to the current node; and the adjacency frequency histogram is used to describe which relationship types have appeared around the current node.

[0202] In one embodiment, for example, node "GPU-01" includes:

[0203] Standard entity name vector: 128-dimensional (obtained from Sentence-BERT);

[0204] Entity type encoding: Computational resources → One-hot [1,0,0,0,0] (5 categories);

[0205] Physical reliability: 0.92;

[0206] Node degree: 3;

[0207] Adjacency frequency histogram: {Assign: 2, Release: 1}.

[0208] For the initial scheduling graph For each edge in the algorithm, an edge feature vector is constructed. The edge feature vector includes at least the following: relation name encoding, relation delay bucket encoding, extraction confidence, and time direction label.

[0209] In one implementation, the relational latency bucket can be divided into four latency buckets: "0 to 3 seconds", "3 to 30 seconds", "30 to 300 seconds", and "more than 300 seconds", in order to reduce the impact of extreme latency values ​​on the stability of network training.

[0210] In one embodiment, for example, the edge (GPU-01, assignment, task A) includes:

[0211] Relationship name encoding: Assignment → One-hot encoding;

[0212] Relationship delay bin coding: 30 seconds → falls into the "3~30 seconds" bin → bin code [0,1,0,0];

[0213] Extraction confidence level: 0.92;

[0214] Time direction marker: positive (1).

[0215] Construct a relation template table, which specifies the head entity type and tail entity type that are allowed to be connected for each standard relation. Using the relation template table, subsequent edge addition is only considered between node pairs that match the type.

[0216] Candidate relation pairs are generated based on the relation template table, temporal proximity, and graph distance.

[0217] In the actual implementation, only node pairs that simultaneously meet the following conditions will enter the candidate set:

[0218] The node type satisfies at least one relation template rule;

[0219] The difference between the node action time anchor points is less than the maximum time window of the candidate relationship;

[0220] The current two nodes are in the initial scheduling graph The texts are not directly connected, but there are weak connection paths of length 2 or 3, or they co-occur repeatedly in adjacent scheduling texts.

[0221] In practice, the maximum time window for candidate relationships can be set according to the relationship template. For example, "Assign-Execute" can be set to 300 seconds, "Complete-Release" can be set to 120 seconds, and "Preempt-Rollback" can be set to 600 seconds.

[0222] All eligible node pairs are written into the candidate relation set for subsequent scoring by the resource constraint graph neural network, which significantly reduces the number of candidate relations and ensures that most candidate relations satisfy the basic scheduling semantic constraints.

[0223] Conventional graph neural networks only fill edges based on structural similarity. For example, they may misjudge "similar time" as "relationship exists" or "frequent co-occurrence" as "allowed connection". This application uses a resource-constrained graph neural network to perform relationship-aware aggregation of nodes and directly introduces the violation factor in the resource constraint table when scoring relationships, realizing the integration of "structural scoring + constraint screening". The specific steps are as follows:

[0224] Initial scheduling graph It is divided into a training edge set, a validation edge set, and a test edge set.

[0225] In practical implementation, existing edges can be divided into a training edge set, a validation edge set, and a test edge set in an 8:1:1 ratio. The real edges in the training edge set are used as positive samples, such as (GPU-01, allocation, task A). Node pairs with matching types but not existing in the graph are extracted from the candidate relation set as negative samples. For example, (GPU-01, allocation, task B) does not exist in the graph and has similar times (10:03:20 and 10:03:15 differ by 5 seconds), and has a matching type (resource → task), so it is used as a negative sample. Among these, negative samples are preferentially selected from node pairs with similar times and matching types but no actual relationship, so that the network learns finer distinguishing boundaries.

[0226] A resource-constrained graph neural network is constructed, consisting of two relation-aware message-passing layers and one relation scoring head. Each relation-aware message-passing layer targets the central node, aggregating the features of its neighboring nodes and edges. The weights of neighbor messages are determined by the features of the central node, neighboring node features, relation name encoding, and relation delay binning. The output of the second layer serves as the final node representation. The final node representation is denoted as... , Represents a node The node representation vectors encoded by the graph neural network are used for subsequent candidate relation scoring.

[0227] In its implementation, the resource constraint graph neural network uses a two-layer relation-aware message-passing layer, with the initial scheduling graph as the input. The system consists of a node feature matrix (each row is a feature vector of a node) and an edge feature matrix (each row is a feature vector of an edge, including relation type encoding and time delay binning). Layer 1: Each node aggregates the features of all its neighbors; the aggregation weight is determined by the current node's features, the features of its neighbors, and the relation type of the connecting edges. Layer 2: The system aggregates again based on the output of Layer 1 to obtain the final node representation vector (a 128-dimensional vector for each node). The output is the final representation matrix of all nodes, used by the subsequent relation scoring head. The relation scoring head is a fully connected layer; its input is the concatenation of the head node representation, tail node representation, and time difference encoding, and its output is the probability of the candidate relation existing.

[0228] For each candidate relation Calculate the relationship score, denoted as . ,in, Indicates the candidate head node. Indicates a candidate tail node. Indicates the candidate relation type. Represents a node With nodes The relationship between them is... The overall score ranges from 0 to 1, and is calculated as follows:

[0229] ,

[0230] in, This represents the Sigmoid function, used to compress scores to a range of 0 to 1. Representing relations The corresponding rating parameter vector, express Transpose of; This indicates vector concatenation; Represents a node With nodes The time difference encoding vector between them; Indicates candidate relationship The corresponding constraint violation factor ranges from 0 to 1, with a larger value indicating a violation of the resource constraint table. The higher the degree.

[0231] In practical implementation, if the candidate relationship directly violates the resource exclusive constraint or priority constraint, then... Setting it to 1 will directly change the overall score to 0; if the candidate relation does not directly violate the hard constraint, but the prediction delay is slightly higher than the delay limit, then it can be set to 1. Set it to a soft penalty value between 0.2 and 0.5.

[0232] Predict relationship latency for candidate relationships selected by relationship scoring.

[0233] In practical implementation, nodes can be... The node represents a vector, a node The node representation vector and candidate relation type encoding are input into a 2-layer fully connected network, and the output is the prediction delay.

[0234] The output layer uses a non-negative activation function to ensure that the prediction delay is not negative;

[0235] If the prediction latency is higher than this type of relationship, in the resource constraint table If the latency limit is not met, the candidate relationship will not be directly written into the complete scheduling graph in subsequent steps, but will instead enter the constraint review process.

[0236] In one embodiment, as an example, suppose the candidate relationship is (GPU-01, Release, Task A Completion Event), and the base score calculated by the relationship scoring head is 0.88, and the resource constraint table... There is a latency limit constraint: the latency limit for the "release" relationship is 30 seconds; in this case, the latency prediction header outputs a predicted latency of 28 seconds. Since 28 seconds ≤ 30 seconds, the latency limit is not violated. The final overall score was still 0.88, and this candidate relationship can proceed to the next screening stage.

[0237] In one embodiment, for example, the same candidate relation may have a predicted latency of 55 seconds, but the latency prediction header output is greater than 30 seconds, violating the latency upper limit constraint. In this case, a setting can be made... (Soft punishment), then the final comprehensive score = If the value is below the edge-filling threshold (e.g., 0.75), the candidate relation is rejected; if a hard penalty is used, it is directly set. With an overall score of 0, the application was also rejected.

[0238] A resource constraint graph neural network is trained using joint loss, which includes: relation existence loss, relation type classification loss, time delay regression loss, and constraint penalty loss.

[0239] In practical implementation, relation existence loss is used to distinguish between positive and negative sample edges; relation type classification loss is used to enable the network to learn to distinguish between different relations such as "allocation", "release", and "dependency"; latency regression loss is used to make the predicted latency close to the actual latency; and constraint penalty loss is used to penalize prediction results that violate resource exclusivity constraints, priority constraints, and latency upper limit constraints.

[0240] In one implementation, the relationship existence loss is calculated using binary cross-entropy, with positive samples labeled 1 and negative samples labeled 0; the relationship type classification loss is calculated using multi-class cross-entropy, predicting the relationship type for each candidate relationship; the time-delay regression loss is calculated using mean squared error (only for positive samples); and the constraint penalty loss is achieved by imposing additional penalties on predictions that violate hard constraints, for example, using... As a penalty item, among which For violating the indicator function, This is the penalty coefficient (e.g., a value of 0.1).

[0241] In practical implementation, the optimizer can be an adaptive moment estimation optimizer, and the initial learning rate can be set to... Batch size can be 16 or 32.

[0242] After training, the resource constraint graph neural network is used to reason about the entire set of candidate relations to obtain the relation score, predicted relation type and predicted latency for each candidate relation.

[0243] In one embodiment, for example, the candidate relationship is "GPU-01-Release-Task A Complete Event", and the base relationship score for the current node pair is 0.88; if the resource constraint table The data indicates that the resource is allowed to be released after task A is completed, and the predicted release delay is 28 seconds, which does not exceed the 30-second delay limit for this type of relationship. The final overall score remains 0.88; if the predicted release delay is 55 seconds, significantly exceeding the delay limit, then... Setting it to 0.5 or even rejecting it outright reduces the probability of incorrect edge patching.

[0244] It should be noted that this application does not first generate unconstrained relations using a graph neural network and then delete edges afterward using a rule table; instead, it directly introduces constraint violation factors into the relation scoring formula. This allows the edge-filling results to be controlled by resource constraints during the generation phase, thereby improving the executability and engineering reliability of the complete scheduling graph.

[0245] In one embodiment, such as Figure 4 As shown, the distribution of relation scores in a resource-constrained graph neural network is analyzed, comparing the distributions of positive samples (real edges) and negative samples (no edges) under the resource-constrained graph neural network. The model can effectively distinguish between real and spurious relations, with positive sample scores significantly higher than negative sample scores. In the figure, the horizontal axis represents the relation score (dimensionless, ranging from 0 to 1), and the vertical axis represents the number of candidate relations (unit: relations). The green histogram represents positive samples, the red histogram represents negative samples, and the blue dashed line indicates the edge-filling threshold of 0.85.

[0246] Step 140: Obtain the predicted latency corresponding to the candidate relationship; calculate the constraint violation factor using the relationship between the candidate relationship, the predicted latency, and the preset resource constraint table; calculate the relationship score of the candidate relationship using the trained resource constraint graph neural network based on the constraint violation factor; complete the candidate relationship between the node combinations in the initial scheduling graph according to the relationship score, the preset resource constraint table, and the trained resource constraint graph neural network, and obtain the completed scheduling graph.

[0247] In some embodiments, the initial scheduling graph The missing relationships in a task often have a chain reaction effect. For example, if the "task completion - resource release" relationship is missing, the subsequent "resource release - queue recycling" relationship will also be difficult to identify. Therefore, relationship completion should be done gradually in multiple rounds rather than performing a single round of static edge completion. The specific steps are as follows:

[0248] Candidate relations with a relation score greater than the edge-filling threshold are added to the edge-filling list. The edge-filling threshold can be set from 0.75 to 0.9. In engineering implementation, 0.85 can be used first to prioritize the retention of high-confidence relations.

[0249] For each candidate relation in the edge supplementation list, perform hard constraint filtering. Hard constraint filtering checks at least three things: whether it violates the resource exclusive constraint, whether it violates the priority constraint, and whether it violates the relation template table.

[0250] If any one condition is not met, the candidate relationship is rejected and not included in the complete scheduling graph.

[0251] For candidate relations that have passed the hard constraint screening, soft constraint screening is performed. Soft constraint screening checks at least whether the predicted delay is close to the delay limit, whether it conflicts with existing high-confidence relations, and whether it forms duplicate semantics with other edges in the same time window.

[0252] In practice, if there is only a slight delay or slight redundancy, the edge confidence is reduced and the edge is retained; if there is a significant conflict, the edge is rejected.

[0253] The new edges that pass the screening are added to the current scheduling graph to obtain the updated scheduling graph. The new edges must include at least the relation name, prediction delay, edge confidence, and source identifier. The edge confidence can be calculated by combining the relation score, relation classification probability, and the reliability of related entities.

[0254] In one embodiment, as an example, the new edge is: (GPU-01, Release, Task A Complete Event), relation score = 0.88, relation classification probability = 0.92, entity reliability = 0.90, edge confidence = (0.88+0.92+0.90) / 3 = 0.90, then write: relation name = release, prediction latency = 28 seconds, edge confidence = 0.90, source identifier = completion_round1 (indicating the edge generated by the first round of iteration completion).

[0255] 5> Using the updated scheduling graph as input, repeatedly perform resource constraint graph neural network reasoning and constraint filtering to form the next round of completion.

[0256] In practice, after each round of completion, the number of newly added edges and the average confidence of the newly added edges are counted. If the number of newly added edges is less than 5% of the current total number of edges for two consecutive rounds, or the average confidence of the newly added edges is lower than the preset lower limit, the iteration stops. The preset lower limit can be between 0.65 and 0.75.

[0257] Output complete scheduling graph ,in, This represents the complete scheduling diagram after completion. Represents a complete set of nodes. Represents the complete set of edges;

[0258] Complete scheduling diagram Each edge in the algorithm must contain at least the relation name, relation delay, edge confidence, source identifier, and completion flag indicating whether it was obtained through completion.

[0259] In one embodiment, as an example, the complete scheduling graph include:

[0260] Nodes: GPU-01, GPU-02, Task A, Task B, Task A completion event, Task B completion event;

[0261] Edge (partial):

[0262] GPU-01--(Assignment, Latency=30s, Confidence=0.92, Completion Mark=Original)-->Task A;

[0263] Task A -- (Completed, Delay = 45s, Confidence = 0.95, Completion Mark = Original) --> Task A Completion Event;

[0264] GPU-01--(Release, Latency=28s, Confidence=0.90, Completion Mark=Completion)-->Task A Complete Event.

[0265] Step 150: Based on the complete scheduling diagram, generate the corresponding conceptual classes, object attributes, and data attributes; based on the complete scheduling diagram and the preset resource constraint table, generate the corresponding conceptual axioms, relational axioms, and scheduling rules with time delay windows, and then unify them into a deployable scheduling domain ontology; deploy the scheduling domain ontology to the resource collaborative scheduling system.

[0266] Complete scheduling diagram While it already contains relatively complete entities, relationships, and temporal attributes, it is still a graph structure and has not yet formed a deployable, reasonable, and maintainable scheduling domain ontology. This application further transforms the complete scheduling graph into concept classes, object attributes, data attributes, axioms, and rules to form the final scheduling domain ontology. The specific steps are as follows:

[0267] This application will include a complete scheduling diagram. The nodes and edges in the graph are promoted to concept classes and attribute definitions at the ontology level, enabling the graph structure to enter the ontology management and rule reasoning stages. The specific steps are as follows:

[0268] According to the complete scheduling diagram The node type labels, entity name patterns, and relationship contexts in the code generate concept classes.

[0269] In practical implementation, nodes whose names contain "GPU", "CPU", "node", or "card" can be classified into the computing resource class; nodes whose names contain "storage volume", "disk", or "object storage" can be classified into the storage resource class; nodes whose names contain "task", "job", or "work order" can be classified into the task entity class; and nodes whose names contain "alarm", "exception", or "fault" can be classified into the alarm event class.

[0270] Furthermore, specific nodes under the same conceptual class are retained as instance items in the scheduling domain ontology. middle.

[0271] Generate a concept hierarchy based on the resource registry and name hierarchy terms.

[0272] In practical implementation, "GPU node" can be used as a subclass of "computing resource", "training task" can be used as a subclass of "task entity", and "network alarm" can be used as a subclass of "alarm event".

[0273] If a clear classification tree already exists in the resource registry, the resource registry classification tree will be used first; if it is missing, a conceptual hierarchy will be automatically generated based on the name pattern and relationships such as "belongs to", "type is", and "instance is" in the diagram.

[0274] In one embodiment, as an example, the resource registry defines three levels: "Computing Resources → GPU Resources → NVIDIA A100". In the diagram, the A100-01 node type is "NVIDIA A100", so the automatically generated A100-01 instance belongs to the NVIDIA A100 class. NVIDIA A100 is a subclass of GPU resources, and GPU resources are a subclass of computing resources.

[0275] According to the complete scheduling diagram The relation name in the table generates object properties, and the object properties include at least: assigned to, released to, dependent on, conflicted to, prioritized to, migrated to, alerted to, and cleared alerted to.

[0276] In the actual implementation, each object attribute is written with its allowed head concept class and tail concept class. For example, the head concept class for "assigned to" is the resource class, and the tail concept class is the task entity class; the head concept class and tail concept class for "depended on" are both the task entity class.

[0277] According to the complete scheduling diagram The edge attributes and source tracing information in the data are used to generate data attributes. The data attributes include at least: relation delay in seconds, edge confidence, action time, source scheduling text number, source event block number, and whether the edge is completed.

[0278] Based on this, the scheduling domain ontology It not only retains information about "who is related to whom and what their relationship is," but also "when the relationship occurred, how long it lasted, its credibility, and where it originated." It is a formalized knowledge base containing: concept classes (such as computing resources, task entities), object attributes (such as allocated to, released to), data attributes (such as relation latency in seconds, edge confidence), axioms (subclassing, disjointness, domain, etc.), and scheduling rules with latency windows. For example, an object attribute definition: the domain of allocated is the computing resource class, and the value domain is the task entity class; a data attribute: the relation latency in seconds is of type xsd:integer; where xsd:integer is a data type defined in XML Schema Definition (XSD) that represents an integer.

[0279] In one embodiment, such as Figure 5 As shown, the hierarchical structure of concept classes is displayed, and the main concept classes and their inheritance relationships in the scheduling domain ontology are displayed in a tree structure. This technology can automatically or semi-automatically generate a hierarchical concept system from a complete scheduling graph.

[0280] Furthermore, concept classes and attribute definitions alone are insufficient to support consistency checks and automated reasoning. This application generates conceptual axioms and relational axioms based on the complete scheduling graph and resource constraint table. The specific steps are as follows:

[0281] The axiom for generating subclasses is as follows: if a group of nodes consistently and stably satisfies both the conditions of "their names contain subordinate resource terms" and "they always appear as instances of the superordinate concept class in the relational context", then it is a subclass generation axiom for them.

[0282] For example, if instances whose names contain "GPU node" are consistently and stably classified as computing resources, then the subclass axiom "GPU node is a subclass of computing resources" is generated.

[0283] The disjoint axiom is generated specifically if two types of concepts are in the resource registry or resource constraint table. If a value is explicitly marked as non-interchangeable, non-substitutable, or mutually exclusive, then an axiom of disjointness is generated for it.

[0284] For example, if certain resource pools are defined as "training-specific resource pools" and "test-specific resource pools", and the scheduling rules explicitly state that the two cannot be allocated interchangeably, then the corresponding disjoint axiom can be generated.

[0285] The axioms for the domain and value range of generated object attributes are as follows: for "assigned to", the axiom is generated that "the domain is the resource class and the value range is the task entity class"; for "conflicts with", the axiom is generated that "the domain is either the resource class or the task entity class and the value range is either the resource class or the task entity class"; and for "precedes", the axiom is generated that "the domain is the task entity class and the value range is the task entity class".

[0286] Generate object attribute characteristic axioms, specifically, if a certain relation exists in the complete scheduling graph If a relationship exhibits a symmetrical structure in the medium to long term, and should indeed be considered a bidirectional relationship in business terms, then a symmetric axiom can be generated for it, such as "conflict with"; if a certain relationship exists in the complete scheduling graph... If a rule table consistently exhibits a transitive structure and there are no counterexamples, then transitive axioms can be generated for it, such as partial "dependency" or "priority" relations.

[0287] It should be noted that not all relationships are automatically assigned symmetric or transitive characteristics. Corresponding axioms are only generated when both historical data and business rules support them, in order to avoid over-expansion of formal expressions.

[0288] The scheduling domain ontology must not only represent static knowledge, but also dynamic scheduling rules that define "under what conditions and for what time period what action should be performed." This application starts from a complete scheduling graph. The process involves identifying high-frequency path patterns and generating scheduling rules with delay windows. The specific steps are as follows:

[0289] In the complete scheduling diagram The enumeration includes path patterns of length 2 to 4. A path pattern represents a chain of relationships consisting of multiple consecutive edges, such as "resource allocation → task execution → task completion → resource release".

[0290] In practice, the path length is preferably limited to 2 to 4. The reason is that a path that is too short is not conducive to expressing complete scheduling semantics, while a path that is too long will lead to a decrease in the number of samples and a decrease in the interpretability of the rules.

[0291] For each type of path pattern, backtrack historical instances. Specifically, using the source scheduling text number of the edge and the action time anchor point, map each path pattern back to the original scheduling text to obtain the complete set of historical instances of that path pattern.

[0292] If the number of historical instances of a certain path pattern is too small, for example, less than 10 times, then scheduling rules will not be generated directly, but samples will continue to be accumulated.

[0293] In one embodiment, as an example, assume that in the complete scheduling graph The path pattern "resource allocation → task execution → task completion → resource release" is enumerated and denoted as the pattern. ; Traverse historical instances: Iterate through all paths in the graph that match the pattern. For example, instance 1: GPU-01 allocation → Task A execution → Task A completion → GPU-01 release, source text number T001, action time anchors are 10:03:15, 10:03:45, 10:04:00, 10:04:28; instance 2: GPU-02 allocation → Task B execution → Task B completion → GPU-02 release, source text number T002, time anchors 10:05:00, 10:05:30, 10:06:00, 10:06:20; ... A total of 120 instances were collected. If a certain pattern (such as "resource allocation → resource release") has only 3 historical instances (less than 10), then no scheduling rule is generated, and the samples continue to accumulate.

[0294] The total time for each path pattern is calculated, and a latency window is generated.

[0295] No. The lower bound of the delay window for each scheduling rule is denoted as The upper bound of the delay window is denoted as , Indicates the first The lower bound of the time window for the scheduling rule. Indicates the first The upper bound of the time window for each scheduling rule.

[0296] In the specific implementation, the total time of the path pattern instances is sorted from smallest to largest, and the 10th percentile and 90th percentile values ​​are taken as... and If the number of instances is small but still reaches the minimum retention limit, a latency window can be generated using the "average ± 1 standard deviation" method, with the lower bound truncated to be no less than 0. For example, if the total time (from allocation to release) for 120 instances is sorted as follows: 10th percentile = 25 seconds, 90th percentile = 35 seconds, then the latency window... Second.

[0297] Convert path patterns into scheduling rules , Indicates the first Each scheduling rule includes at least the following: preconditions, scheduling action, delay window, and rule confidence level.

[0298] In practical implementation, the preconditions are obtained by combining the critical relationships on the path's starting point and intermediate edges, the scheduling action is determined by the action at the end of the path, and the delay window adopts... For example, if a large number of historical instances satisfy the condition that "resources have been allocated to tasks and the resources will be released within 25 to 35 seconds after the tasks enter the completion state", then a scheduling rule of "when resources have been allocated to tasks and the tasks enter the completion state, resource release will be performed within 25 to 35 seconds" will be generated.

[0299] The rule confidence is calculated by considering two factors: path instance support and path edge average confidence. The higher the support and the higher the path edge average confidence, the higher the rule confidence. The rule confidence can be used for subsequent rule retention and conflict resolution.

[0300] In one embodiment, taking the path pattern "resource allocation → task completion → resource release" as an example, there are 120 historical instances. The average confidence of the path edges is calculated as follows: each instance contains 3 edges (allocation, completion, release), and the average confidence of each edge is calculated separately. This is then averaged across the 120 instances, resulting in a score of 0.88. The support of the path instances is calculated as follows: this pattern appears 120 times, and the total number of path pattern instances (cumulative across all patterns) is 500. Therefore, the support score is 120 / 500 = 0.24. The rule confidence score is calculated as: support × 0.5 + average confidence of path edges × 0.5 = 0.24 × 0.5 + 0.88 × 0.5 = 0.56. If the retention threshold is 0.7, the rule is not retained. If the support score is higher (e.g., 0.5) and the average edge confidence score is 0.9, then the confidence score is 0.7, and the rule can be retained.

[0301] Filter and merge scheduling rules. Specifically, only retain scheduling rules whose confidence level is higher than the rule retention threshold, which can be set to 0.7.

[0302] If two scheduling rules have the same preconditions, the same scheduling actions, and a delay window overlap of more than 80%, then the two scheduling rules will be merged. If the two scheduling rules have similar preconditions but different scheduling actions, then rule conflict detection will be performed, and the scheduling rule with higher confidence, higher support, and more up-to-date source update time will be retained first.

[0303] In one embodiment, the complete scheduling graph The path pattern "GPU-01 assigned to task A → task A completed → GPU-01 released" appears multiple times. After analyzing 100 historical instances, the 10th percentile of the total path time is 25 seconds, the 90th percentile is 35 seconds, and the rule confidence is 0.86. Therefore, the generation of the [missing information]... scheduling rules When the given condition is "GPU resources have been allocated to a task and the task has entered the completed state", the scheduling action should be "release the GPU resources", and the execution time window is 25 to 35 seconds.

[0304] This application unifies the aforementioned conceptual classes, object attributes, data attributes, axioms, and scheduling rules into a deployable scheduling domain ontology. Specifically:

[0305] The concept classes, object attributes, data attributes, and axioms are organized into the ontology definition; scheduling rules are... Organize it into the rule definition section.

[0306] In practice, the ontology definition is exported as an OWL file, and the rule definition is exported as an independent rule file. The separation of "ontology file + rule file" makes it easier to update the rules separately without having to rebuild the entire ontology structure.

[0307] In one embodiment, the ontology definition is exported as a sched_ontology.owl file, containing classes, attributes, and axioms; the rule definition is exported as a sched_rules.drl (Drools format) or a JSON file, for example:

[0308] {

[0309] "rule_id":"R001", / / Unique identifier for the rule;

[0310] "precondition":"Resources have been allocated to the task AND task status = completed", / / Prerequisite condition for rule triggering (logical expression);

[0311] "action":"Release resources", / / The scheduling action to be executed after the prerequisite is met;

[0312] "time_window":[25,35], / / Time window, in seconds:[lower bound,upper bound], indicates that the action should be executed within this time range;

[0313] "confidence":0.86 / / Rule confidence, between 0 and 1, representing an estimate of the rule's reliability.

[0314] Perform ontology consistency checks and rule conflict checks, specifically...

[0315] Ontology consistency checks include at least the following:

[0316] Does a circular subclass relationship exist? Does the domain and value range of an object attribute conflict? Are there cases where disjoint concepts are simultaneously satisfied by the same instance?

[0317] Rule conflict checks include at least:

[0318] Are there rules for giving mutually exclusive scheduling actions under the same preconditions? Are there rules for conflicting delay windows?

[0319] If a conflict exists, the definition with higher rule confidence, higher support, and more up-to-date source time will be retained.

[0320] The results of consistency checks and conflict checks will be combined to form the scheduling domain ontology. Scheduling domain ontology It should include at least: a set of concept classes, a set of object attributes, a set of data attributes, a set of axioms, and a set of scheduling rules.

[0321] Optionally, source tracing information can also be written into the scheduling domain ontology. This is included in the extended fields for subsequent manual verification and continuous updates.

[0322] The system provides a calling interface description. Specifically, the input to the calling interface is the current resource status, the current task status, and the newly added scheduling text. The calling interface first performs knowledge extraction and entity alignment on the newly added scheduling text, and then maps the new relationship to the scheduling domain ontology. In the end, based on the scheduling domain ontology The concepts, axioms, and scheduling rules in the output suggest scheduling actions, reference delay windows, and hit rule numbers.

[0323] Based on this, the scheduling domain ontology It not only provides offline build results, but can also participate in online scheduling and decision support, serving as a scheduling domain ontology. It is a formal knowledge base that can be exported as OWL files (ontology definitions) and rule files.

[0324] After constructing the scheduling domain ontology, this application deploys it into a practical resource collaborative scheduling system to assist in online scheduling decisions. The scheduling domain ontology includes concept classes, object attributes, data attributes, axioms, and scheduling rules with time windows. This knowledge formally describes various relationships between resources and tasks and their time constraints. During the operation of the scheduling system, whenever new scheduling text is generated (e.g., new scheduling logs, work order records, or alarm handling records), the system first performs knowledge extraction and entity alignment on that text.

[0325] Specifically, the new text undergoes text standardization, candidate event sentence segmentation, time anchor completion, event block partitioning, extraction of original knowledge fragments from a large language model based on dynamic prompts, and cross-scheduling text entity alignment to obtain a new set of relations consistent with existing standard entity names. These new relations are temporarily represented in the form of a graph structure and carry action time anchors, relation delays, extraction confidence, and source tracing information.

[0326] Then, the scheduling system reads the current resource and task status. Resource status includes the current occupancy of various computing, storage, and network resources, their occupancy time windows, and resource exclusivity flags. Task status includes the execution stage (waiting, running, completed, exception, etc.), priority, and a list of allocated resources for each task. The system compares the current status with the conceptual classes and object attributes of the ontology, using axioms for consistency checks. For example, it checks whether the same exclusive resource is allocated to two different tasks within the same time window. If an inconsistency is found, an alarm is triggered and illegal scheduling is prevented.

[0327] Then, the system matches the newly extracted relationships and the current state against the entity's set of scheduling rules. Each scheduling rule includes preconditions, scheduling actions, a latency window, and rule confidence. The matching process uses a rule engine (e.g., a rule engine based on the Rete algorithm) to perform pattern matching between the facts in the current state (such as "GPU-01 has been assigned to task A" and "Task A is in the completed state") and the rule's preconditions. When a rule's preconditions are met, the system generates a suggestion based on the rule's scheduling action and provides the expected execution time range with reference to the latency window provided by the rule. For example, if the rule stipulates that "when a resource has been assigned to a task and the task has entered the completed state, the resource should be released within 25 to 35 seconds," the system calculates the suggested release time window based on the current time and outputs the suggestion to the scheduling execution module. If multiple rules are matched at the same time and their scheduling actions conflict (for example, one rule suggests releasing resources while another rule suggests reserving resources for subsequent tasks), the system will make a decision based on the confidence level of the rules, prioritizing the rule with higher confidence. It can also combine manually set strategies (such as conservative priority or performance priority) for a comprehensive judgment.

[0328] In addition to rule-based reasoning, the system can also utilize data attributes from the scheduling ontology (such as relation latency in seconds, edge confidence, and action time) for statistical analysis to dynamically adjust the boundaries of the latency window. For example, when the completion latency of a certain type of relation frequently exceeds the upper bound of the ontology's latency window during actual scheduling execution, the system can record this phenomenon as experience feedback and periodically (e.g., weekly) re-execute latency window statistics to update the time constraints in the scheduling rules. Furthermore, the system provides services externally through API calls. The input to the API is the current resource status, the current task status, and the newly added scheduling text; the output is the suggested scheduling action, the reference latency window, and the hit rule number. The scheduling execution module issues scheduling instructions (such as allocating resources, starting tasks, and releasing resources) based on these outputs and writes the execution results back to the scheduling log, forming a closed-loop feedback.

[0329] As described above, this embodiment does not rely on a fixed text length. Instead, it assigns a uniform time anchor point to each statement by parsing explicit time, relative time, and sequence description. Based on the changes in time interval, action type, and participating objects, it clusters discrete scheduling text statements into complete event blocks according to time continuity and scheduling semantics, effectively preserving cross-sentence scheduling constraint information.

[0330] This application incorporates the original text of the current event block, the summary of adjacent event blocks, and the temporal context into a dynamic prompt, driving the large language model to directly output structured knowledge fragments containing head entities, relations, tail entities, action time anchors, and second-level relational delays. This ensures that time-sensitive relations are accurately captured during the extraction stage, rather than being completed afterward.

[0331] This application comprehensively considers name similarity (edit distance), contextual semantic similarity (cosine similarity of entity description vectors), and type consistency to make multi-dimensional judgments on candidate entity pairs, and prioritizes the use of official names or high-frequency complete names in the resource registry as standard entity names, effectively solving the problem of heterogeneous entity reference in scheduling scenarios.

[0332] This application pre-constructs a constraint table containing resource exclusivity, priority, and latency limits, and designs a graph neural network that directly incorporates constraint violation factors into the relation scoring formula. This network simultaneously applies pre-defined resource constraint table penalties when generating candidate relations, ensuring the completion result is executable from the outset and avoiding the deletion of a large number of invalid edges later.

[0333] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A resource collaborative scheduling method that integrates ontology models and large models, characterized in that, The method includes: Acquire scheduling text data; there is a preset number of labeled scheduling text data; assign time anchors to each candidate event statement in the scheduling text data, and then use the labeled scheduling text data to identify the participating objects in the candidate event statements, and then use the time anchors, participating objects, and action types to divide the scheduling text data into several event blocks to obtain an event block sequence; Based on the event block sequence, a dynamic prompt is constructed for each event block; based on the dynamic prompt, a large language model is invoked to perform structured extraction on each event block to obtain original knowledge fragments; source tracing information is attached to the original knowledge fragments to obtain an original knowledge fragment set; the similarity between the entity description vectors corresponding to entities in the original knowledge fragment set is used to perform entity merging and alignment operations; the original knowledge fragment set with completed entity alignment operations is used to generate an initial scheduling graph. Based on the preset resource registry, preset scheduling rule table, and initial scheduling graph, a preset resource constraint table is constructed; based on the preset entity relationship template table and the time anchor point difference between node actions in the initial scheduling graph, a candidate relationship set containing node combinations that satisfy the preset resource constraint table is constructed. Obtain the predicted latency corresponding to the candidate relationship; calculate the constraint violation factor using the relationship between the candidate relationship, the predicted latency, and the preset resource constraint table; calculate the relationship score of the candidate relationship using the trained resource constraint graph neural network based on the constraint violation factor; and complete the candidate relationship between the node combinations in the initial scheduling graph according to the relationship score, the preset resource constraint table, and the trained resource constraint graph neural network to obtain the complete scheduling graph. Based on the complete scheduling diagram, generate corresponding conceptual classes, object attributes, and data attributes; based on the complete scheduling diagram and the preset resource constraint table, generate corresponding conceptual axioms, relational axioms, and scheduling rules with time delay windows, and then unify them into a deployable scheduling domain ontology; deploy the scheduling domain ontology to the resource collaborative scheduling system.

2. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Retrieve scheduling text data and assign time anchors to each candidate event statement in the scheduling text data, specifically including: Collect scheduling text data generated during the operation of the scheduling system covering the entire scheduling cycle; the annotation adopts the sequence annotation method, obtains the entity class annotation data corresponding to a preset number of scheduling text data, and obtains a preset number of annotated scheduling text data; Perform text standardization processing on the scheduling text data; By using a combination of preset punctuation and preset action words, the standardized scheduling text data is segmented into several candidate event statements. When multiple preset action words appear in a candidate event statement, the candidate event statement is further segmented according to the position of the action words. Extract time representations from candidate event statements; when the time representation is a specific time, convert it to a standard time; when the time representation is a non-specific time, determine the corresponding standard time based on the preset offset time corresponding to the non-specific time and the standard time corresponding to the previous time representation; when a candidate event statement has a standard time, determine the standard time as the time anchor point; when a candidate event statement does not have a standard time, determine the time anchor point of the current candidate event statement based on the time anchor points of the previous and next candidate event statements.

3. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Using labeled scheduling text data, the participating objects in candidate event statements are identified. Then, using time anchors, participating objects, and action types, the scheduling text data is divided into several event blocks to obtain an event block sequence, specifically including: Using the scheduling text data of the labeled participants, a named entity recognition model is trained to obtain a well-trained named entity recognition model. Using a trained named entity recognition model, identify the participating objects in candidate event statements; Read the action type from the candidate event statement; Based on time anchors, action types, and participating objects, identify whether the candidate event statements corresponding to scheduling text data show changes in the preset time anchor interval, action changes, or participating objects; When there is a change in the preset time anchor interval, a change in action, or a change in the participating object, the candidate event statement is divided into two event blocks, and then the event block sequence is obtained.

4. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Based on the event block sequence, construct dynamic prompts for each event block; Based on dynamic prompts, a large language model is invoked to perform structured extraction on each event block to obtain raw knowledge fragments. Source tracing information is then appended to these raw knowledge fragments to obtain a set of raw knowledge fragments, specifically including: Based on the event block sequence, dynamic prompts are constructed for the content according to the original text of the current event block, the summary of the previous event block, the summary of the next event block, and the preset field output format requirements. The preset field output format requirements include: header entity, relation, tail entity, time anchor, relation delay, extraction confidence, and evidence fragment. Based on dynamic prompts, a large language model is invoked to perform structured extraction on each event block to obtain raw knowledge fragments; among which, the raw knowledge fragments include at least: head entity, relation, tail entity, time anchor, relation delay, extraction confidence, and evidence fragments. Preprocess the original knowledge fragments and remove those that do not meet the preset requirements; Obtain the source tracing information of each original knowledge fragment, attach the source tracing information to the original knowledge fragment, and obtain the original knowledge fragment set; wherein, the source tracing information includes at least: scheduling text number, event block number, and original text position of evidence fragment.

5. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Perform entity merging and alignment operations based on the similarity between the entity description vectors corresponding to entities in the original knowledge fragment set; An initial scheduling graph is generated using the original set of knowledge fragments that have undergone entity alignment operations, specifically including: Standardize and unify the names of all entities in the original set of knowledge fragments; An entity description vector is generated for the entity after standardized and unified processing; the entity description vector is jointly encoded by the entity name, the evidence fragment in which the entity is located, the name of the adjacent relationship, and the entity type; Based on the preset similarity relationship, candidate entity pairs are generated from all entities; Calculate the similarity between the entity description vectors of candidate entity pairs; where the similarity includes: name similarity, context similarity, and type consistency; when the similarity meets the preset merging condition value, perform the candidate entity pair merging and alignment operation; and switch the merged entity name to the preset standard name; Obtain the original knowledge fragment set after entity alignment operation, and use the preset standard data dictionary to convert the entity names in the original knowledge fragment set into standard names and the relation names in the original knowledge fragment set into standard relation names; Nodes of the initial scheduling graph are generated based on the entities in the original knowledge fragment set, and edges of the initial scheduling graph are generated based on the relationships in the original knowledge fragment set.

6. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Based on the preset resource registry, preset scheduling rule table, and initial scheduling graph, construct a preset resource constraint table; Based on the time anchor point difference between node actions in the preset entity relationship template table and the initial scheduling graph, a candidate relationship set is constructed, which includes node combinations that satisfy the preset resource constraint table. Specifically, this set includes: Based on the preset resource registry, preset scheduling rule table, and initial scheduling graph, a preset resource constraint table is constructed; wherein, the preset resource constraint table includes at least: resource exclusivity constraint, priority constraint, and latency limit constraint; Construct a node feature vector for each node in the initial scheduling graph; wherein the node feature vector includes at least: standard entity name vector, entity type code, entity reliability, node degree, and adjacency frequency histogram; Construct an edge feature vector for each edge in the initial scheduling graph; wherein the edge feature vector includes at least: relation name encoding, relation delay bucket encoding, extraction confidence, and time direction label; Retrieve a preset entity relationship template table that specifies the head and tail entity types that are allowed to be joined for each standard relationship; When any pair of nodes satisfies at least one rule in the preset entity relationship template table, and the time anchor difference is less than the maximum time window of the candidate relationship, and the pair of nodes is not directly connected in the initial scheduling graph, and there is a connection path of preset length or the number of co-occurrences in adjacent scheduling text data is greater than the preset number, it is determined as a candidate relationship, and then a set of candidate relationships is constructed.

7. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Before using the trained resource-constrained graph neural network to calculate the relationship score of candidate relationships between node combinations, the method further includes: The training scheduling graph is divided into a training edge set, a validation edge set, and a test edge set. The real edges in the training edge set are used as candidate relations for positive samples; the node pairs that match the type but do not exist in the scheduling graph are extracted from the candidate relation set corresponding to the training scheduling graph as candidate relations for negative samples. A resource-constrained graph neural network is constructed, consisting of two relation-aware message passing layers and one relation scoring head. Each relation-aware message passing layer targets the central node and aggregates the features of its neighboring nodes and edges. The weights of neighboring messages are determined by the features of the central node, the features of neighboring nodes, the relation name encoding, and the relation delay binning. The output of the second layer serves as the final representation of the node. The node feature vectors and edge feature vectors of the training scheduling graph are input into the resource constraint graph neural network, and the final representation vectors of all nodes are output through a two-layer relation-aware message passing layer. Through the formula: The computation node u and node v belong to the candidate relationship. Relationship rating ; in, Represents the Sigmoid function; Representing relations The corresponding rating parameter vector, express Transpose of; This indicates vector concatenation; Represents a node With nodes The time difference encoding vector between them; Indicates candidate relationship The corresponding constraint violation factor ranges from 0 to 1. This represents the final representation vector of node u. This represents the final representation vector of node v; Relationship between node u and node v, and candidate relationships. Input a fully connected network, output the predicted latency; When a candidate relationship does not meet the resource exclusivity constraint or priority constraint in the preset resource constraint table, Set to 1 to score the initial relationship. The value is reduced to 0; when a candidate relationship meets the resource exclusivity constraint and priority constraint in the preset resource constraint table but the predicted latency is higher than the latency upper limit constraint in the preset resource constraint table, it will be... Set within the preset soft penalty value range; In the training process of the resource-constrained graph neural network, joint loss is used to train the resource-constrained graph neural network; the joint loss includes: relation existence loss, relation type classification loss, time delay regression loss and constraint penalty loss.

8. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Obtain the predicted latency corresponding to the candidate relationship between node combinations, and calculate the constraint violation factor using the relationship between the candidate relationship, the predicted latency, and the preset resource constraint table; Based on the constraint violation factor, a pre-trained resource constraint graph neural network is used to calculate the relationship score of candidate relationships between node combinations, specifically including: Input the node combination and candidate relationship into the fully connected network, and output the predicted latency; When a candidate relationship does not meet the resource exclusive constraint or priority constraint in the preset resource constraint table, the constraint violation factor is set to 1; when a candidate relationship meets the resource exclusive constraint and priority constraint in the preset resource constraint table but the prediction latency is higher than the latency upper limit constraint in the preset resource constraint table, the constraint violation factor is set to the preset soft penalty value range. The node feature vector of the node combination and the edge feature vector of the candidate relationship are input into the resource constraint graph neural network, and the final representation vector of the node is output through a 2-layer relationship-aware message passing layer. By substituting the constraint violation factor and the final representation vector into the preset relationship scoring formula, the relationship score of the candidate relationship between node combinations is calculated.

9. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Based on relationship scoring, a pre-defined resource constraint table, and a trained resource constraint graph neural network, candidate relationships between node combinations in the initial scheduling graph are completed to obtain the complete scheduling graph. Specifically, this includes: Add candidate relations whose relation scores are greater than the preset edge-filling threshold to the edge-filling list; Verify whether the candidate relationships in the list of edges to be filled meet the resource exclusive constraints and priority constraints in the preset resource constraint table. If they do not meet the resource exclusive constraints and priority constraints, remove them from the list of edges to be filled. Verify whether the candidate relations in the list of edges to be supplemented meet the time limit constraint in the preset resource constraint table, whether there is a preset high confidence relation conflict, and whether they form duplicate semantics with the edges in the same time window. If they only do not meet the time limit constraint and the difference is less than the preset difference threshold, reduce the confidence of the corresponding edge; otherwise, remove it from the list of edges to be supplemented. Add the edges from the list of edges to be supplemented to the initial scheduling graph to obtain the completed scheduling graph; where the edge confidence is calculated by combining the relationship score, the relationship classification probability and the corresponding entity reliability. After obtaining the completed scheduling graph, the number of newly added edges and the average confidence of newly added edges are counted. If the number of newly added edges and the average confidence of newly added edges meet the preset stopping condition for two consecutive rounds, the current completed scheduling graph is taken as the complete scheduling graph. If the preset stopping condition is not met, the completed scheduling graph will be input into the trained resource constraint graph neural network again to obtain the completed scheduling graph, until the preset stopping condition is met and the complete scheduling graph is obtained.

10. The resource collaborative scheduling method for fusing ontology models and large models according to claim 1, characterized in that, Based on the complete scheduling graph, corresponding conceptual classes, object attributes, and data attributes are generated; based on the complete scheduling graph and the preset resource constraint table, corresponding conceptual axioms, relational axioms, and scheduling rules with delay windows are generated, and then unified into a deployable scheduling domain ontology, specifically including: Generate concept classes based on node type labels, entity name patterns, and relationship contexts in the complete scheduling graph; Generate hierarchical concepts based on the pre-defined resource registry and the corresponding name hierarchy words of the node names; Data attributes are generated based on the edge attributes and source tracing information in the complete scheduling graph; the data attributes include at least: relationship delay in seconds, edge confidence, action time, source scheduling text number, source event block number, and whether the edge is completed. Generate conceptual axioms and relational axioms based on the complete scheduling diagram and the preset resource constraint table; Obtain the preset high-frequency path pattern from the complete scheduling graph and generate scheduling rules with a time delay window.

Images