Scheduling problem generation method and device, equipment and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for generating scheduling problems. This application relates to the field of electronic data processing technology. The method includes: constructing a hierarchical knowledge representation structure for the target scheduling domain, the hierarchical knowledge representation structure comprising a general concept layer and an instance data layer; performing semantic planning based on the hierarchical knowledge representation structure to generate an intermediate description scheme for the corresponding scheduling problem; performing constraint enhancement processing based on the intermediate description scheme to generate target problem model data; and performing feasibility verification on the target problem model data to obtain a logically consistent and solvable scheduling problem.

Description

Technical Field

[0001] This application relates to the field of electronic data processing technology, and in particular to a method, apparatus, device and storage medium for generating scheduling problems. Background Technology

[0002] In scenarios involving complex and critical elements such as tasks, resources, and time, such as industrial environments or project management, large-scale models are often used to optimize the scheduling of these key elements to achieve preset optimization goals, such as minimizing project duration and maximizing resource utilization. In this case, large-scale models can construct scheduling problems corresponding to the scheduling scenario to optimize the scheduling optimization capabilities of that scenario.

[0003] However, existing methods for constructing and generating scheduling problems still have significant shortcomings. Most current research relies on manually defined instances or randomly generated rules. These methods typically only cover a limited number of constraint types and are prone to generating unreasonable or even infeasible scheduling problem data. In other words, existing methods for generating scheduling problems suffer from low reliability and poor practicality.

[0004] Therefore, improving the reliability and usability of the generated call problem data has become an urgent issue to be addressed. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, device, and storage medium for generating scheduling problems, aiming to solve the technical problem of how to improve the reliability and usability of the generated scheduling problem data.

[0006] To achieve the above objectives, this application proposes a scheduling problem generation method, which includes:

[0007] A hierarchical knowledge representation structure for the target scheduling domain is constructed, which includes a general concept layer and an instance data layer. Semantic planning is performed based on the hierarchical knowledge representation structure to generate an intermediate description scheme for the corresponding scheduling problem. Constraint enhancement processing is performed based on the intermediate description scheme to generate target problem model data; The feasibility of the target problem model data is verified to obtain a logically consistent and solvable scheduling problem.

[0008] Furthermore, to achieve the above objectives, this application also proposes a scheduling problem generation apparatus, which includes: The structure generation module is used to construct a hierarchical knowledge representation structure for the target scheduling domain, wherein the hierarchical knowledge representation structure includes a general concept layer and an instance data layer. The scheme processing module is used to perform semantic planning based on the hierarchical knowledge representation structure and generate an intermediate description scheme for the corresponding scheduling problem. The constraint module is used to perform constraint enhancement processing based on the intermediate description scheme to generate target problem model data; The problem generation module is used to perform feasibility verification on the target problem model data to obtain a logically consistent and solvable scheduling problem.

[0009] In addition, to achieve the above objectives, this application also proposes a scheduling problem generation device, which includes: a memory, a processor, and a scheduling problem generation program stored in the memory and executable on the processor. The scheduling problem generation program is configured to implement the steps of the scheduling problem generation method described above.

[0010] In addition, to achieve the above objectives, this application also provides a storage medium storing a program that implements a scheduling problem generation method, the program being executed by a processor to implement the steps of the scheduling problem generation method as described above.

[0011] This application provides a method, apparatus, device, and storage medium for generating scheduling problems. The method includes: constructing a hierarchical knowledge representation structure for the target scheduling domain, the hierarchical knowledge representation structure including a general concept layer and an instance data layer; performing semantic planning based on the hierarchical knowledge representation structure to generate an intermediate description scheme for the corresponding scheduling problem; performing constraint enhancement processing based on the intermediate description scheme to generate target problem model data; and performing feasibility verification on the target problem model data to obtain a logically consistent and solvable scheduling problem.

[0012] This application first constructs a hierarchical knowledge representation structure, providing a systematic and standardized knowledge foundation for generating scheduling problems in the target scheduling domain, ensuring the accuracy and consistency of terminology. Then, based on the hierarchical knowledge representation structure, semantic planning is performed to generate intermediate description schemes for standardized problem elements corresponding to the scheduling problem, providing a clear basis for subsequent constraint enhancement processing. Simultaneously, this application can systematically add additional constraints and standardize constraint naming through constraint enhancement processing, generating target problem model data that more closely resembles real-world scenarios. Finally, this application can ensure the logical consistency and solvability of the final generated scheduling problem through feasibility verification of the target problem model data. Therefore, the overall scheduling problem generation scheme proposed in this application achieves automated and scalable generation of scheduling problems, and improves the reliability and practicality of the generated scheduling problems. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a flowchart illustrating the first embodiment of the scheduling problem generation method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the scheduling problem generation method of this application; Figure 3 This is a schematic diagram of the process of the second embodiment of the scheduling problem generation method of this application; Figure 4 A simplified schematic diagram of the scheduling problem generation method in this application; Figure 5 This is a schematic diagram of the module structure of the scheduling problem generation device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the scheduling problem generation method in this application embodiment.

[0016] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0018] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0019] The main solution of this application is as follows: constructing a hierarchical knowledge representation structure for the target scheduling domain, which includes a general concept layer and an instance data layer; performing semantic planning based on the hierarchical knowledge representation structure to generate an intermediate description scheme for the corresponding scheduling problem; performing constraint enhancement processing based on the intermediate description scheme to generate target problem model data; and performing feasibility verification on the target problem model data to obtain a logically consistent and solvable scheduling problem.

[0020] Currently, the construction and generation of scheduling problems mostly rely on manually defined instances or randomly generated rules. These methods typically only cover a limited range of constraint types. Therefore, the generated scheduling problem sets cannot fully reflect the complexity and diversity of real industrial environments, leading to discrepancies between the testing and evaluation of scheduling models and actual conditions.

[0021] Furthermore, due to the lack of systematic management of the dependencies and logical order between constraints, current generation methods often produce unreasonable or even infeasible scheduling models—for example, generating conflicting constraint combinations that make the problem unsolvable, or generating scheduling schemes that deviate from the parameter distribution of the actual application scenario, thus losing their application value. Therefore, existing problem generation methods suffer from low reliability and poor practicality.

[0022] To address this issue, this application proposes a multi-agent framework based on knowledge graphs (KGs). By effectively utilizing information in knowledge graphs, it automatically selects and adds constraints, and automatically generates scheduling problems with multiple constraints and objective functions in batches, while ensuring the feasibility and logical consistency of the scheduling problems.

[0023] This application first constructs a hierarchical knowledge representation structure, providing a systematic and standardized knowledge foundation for generating scheduling problems in the target scheduling domain, ensuring the accuracy and consistency of terminology. Then, based on the hierarchical knowledge representation structure, semantic planning is performed to generate intermediate description schemes for standardized problem elements corresponding to the scheduling problem, providing a clear basis for subsequent constraint enhancement processing. Simultaneously, this application can systematically add additional constraints and standardize constraint naming through constraint enhancement processing, generating target problem model data that more closely resembles real-world scenarios. Finally, this application can ensure the logical consistency and solvability of the final generated scheduling problem through feasibility verification of the target problem model data. Therefore, the overall scheduling problem generation scheme proposed in this application achieves automated and scalable generation of scheduling problems, and improves the reliability and practicality of the generated scheduling problems.

[0024] It should be noted that the executing entity in this embodiment can be a scheduling problem generation system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a scheduling problem generation device capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses a scheduling problem generation device (hereinafter referred to as the generation device) as the executing entity to describe this embodiment and the following embodiments.

[0025] It is easy to understand that the scheduling problem to be generated in this application can refer to the problem of rationally arranging elements such as tasks, resources, and time in scenarios such as industrial production and project management to achieve a preset optimization objective (such as minimizing the project duration or maximizing resource utilization). Its core purpose is to optimize the objective function while satisfying a series of constraints. Based on this, embodiments of this application provide a scheduling problem generation method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the scheduling problem generation method of this application.

[0026] In this embodiment, the scheduling problem generation method includes steps S10 to S40: Step S10: Construct a hierarchical knowledge representation structure for the target scheduling domain, wherein the hierarchical knowledge representation structure includes a general concept layer and an instance data layer; Understandably, the aforementioned hierarchical knowledge representation structure can be a structured data form that stores and organizes domain knowledge corresponding to the target scheduling domain (such as assembly line scheduling, job shop scheduling, etc. in the aforementioned industrial production scenario) in layers, such as structured documents or knowledge graphs. In this embodiment, the hierarchical knowledge representation structure may include a general concept layer and an instance data layer. The general concept layer may store general theoretical knowledge corresponding to the target scheduling domain, and the instance data layer may store actual data involved in the specific scheduling process of the target scheduling domain. The two can work together to provide knowledge support for the generation of subsequent scheduling problems.

[0027] Step S20: Based on the hierarchical knowledge representation structure, perform semantic planning to generate an intermediate description scheme for the corresponding scheduling problem; It is important to understand that in the semantic planning process described above, the generating device can extract, organize, and standardize the core elements of the scheduling problem corresponding to the target scheduling domain based on knowledge in the hierarchical knowledge representation structure, using specific algorithms and pre-defined language models (such as GPT series models, Claude models, etc.). This results in intermediate results with clear logical relationships and standardized formats, namely, the aforementioned intermediate description scheme. Therefore, the aforementioned intermediate description scheme can be a structured and standardized description of the core elements of the scheduling problem in the corresponding target scheduling domain, providing a clear basis for subsequent constraint enhancement processing.

[0028] Step S30: Perform constraint enhancement processing based on the intermediate description scheme to generate target problem model data; It should be noted that the above-mentioned constraint enhancement processing can refer to the process of enriching and improving the constraint system of the scheduling problem by systematically adding secondary constraints on the basis of the intermediate description scheme, so that the subsequent scheduling model trained based on the target problem model data is closer to the actual application scenario and the scheduling logic is more rigorous.

[0029] At this point, the target problem model data generated after constraint enhancement processing can be complete scheduling model data containing standard static titles, standard constraint names, mathematical model descriptions, etc., which can be directly used to train the scheduling model.

[0030] Step S40: Perform feasibility verification on the target problem model data to obtain a logically consistent and solvable scheduling problem.

[0031] It should be understood that, in this embodiment, the aforementioned feasibility verification can refer to the process of converting the target problem model data into executable code and running it, and then determining whether the target problem model data is logically consistent and whether a feasible solution exists.

[0032] It is easily understood that the current lack of an effective feasibility verification mechanism for generated scheduling problems leads to the use of some logically contradictory and unsolvable problem data in the scheduling model, wasting a significant amount of computing resources and time. Simultaneously, the inability to promptly detect defects in the generated scheduling problem data easily affects the efficiency and reliability of scheduling problem generation. To address this problem, in a feasible implementation, in this embodiment, step S40 may include steps S41-S43: Step S41: Convert the target problem model data into executable code, wherein the executable code includes variable definitions, optimization functions, and constraint information; It should be noted that the aforementioned executable code can be computer program code (such as Python code) generated based on the target problem model data and can be run by a specific solver (such as Gurobi). For example, in this embodiment, the generation device may have a built-in code generation module that stores the mapping relationship between the target problem model data and the executable code, and the executable code is automatically generated by inputting the target problem model data into the code generation module.

[0033] It should be understood that, in this embodiment, the executable code may contain core content such as variable definitions, objective function code implementation, and constraints, and can be executed by a specific solver to output the solution results.

[0034] Variable definitions, which define decision parameters in the scheduling problem within the executable code, specify attributes such as the variable's type and value range. For example, a job assignment variable might be defined as indicating whether a job is assigned to a machine and the assignment order; a time variable might be defined as indicating the job's start time, finish time, etc. For instance, a binary variable `x_ij` might be defined as indicating whether job `i` is assigned to machine `j` (`x_ij=1` indicates assignment, `x_ij=0` indicates no assignment); a continuous variable `S_i` might be defined as the start time of job `i`, and `C_i` as the finish time of job `i`, etc. It's easy to understand that these variable definitions define the solution space of the problem. Typically, when solving scheduling problems, these variables can be optimized to achieve the optimal value of the objective function.

[0035] The optimization function can be a functional expression corresponding to the quantity that needs to be optimized in the scheduling problem. It usually represents the objective that we want to minimize or maximize, such as minimizing the total completion time (Makespan) or maximizing machine utilization. The optimization function is usually related to variables, and the generating device can iteratively adjust the value of the optimization function by adjusting the variables, thereby achieving scheduling optimization.

[0036] Constraint information can be the restrictions that the generating device must adhere to when solving scheduling optimization problems, such as resource constraints (each resource can only process one task at a time) and time constraints (tasks must be completed within a specific time). Constraint information is typically used to determine the range of limited feasible solutions corresponding to the scheduling problem, ensuring that the scheduling scheme generated by the subsequently trained scheduling model meets the actual operational requirements and improves the practicality of the generated scheduling problem.

[0037] It is easy to understand that, in addition to the parameters mentioned above, the executable code can also include necessary library import statements (such as "import gurobipy as gp"), model initialization statements, solution statements, and result output statements to form a complete code structure.

[0038] Step S42: Execute the executable code and obtain the solution result, which includes feasible key information or infeasibility diagnostic information; It should be understood that the generation device can input the generated executable code into a built-in specific solver and start the solver to execute the code. In this case, the aforementioned key feasibility information can refer to the key solution elements generated when the executable code has a solution result. In this embodiment, the key solution elements may include the optimal objective value and key decision variables.

[0039] The optimal objective value is the numerical value of the objective function corresponding to the optimal solution. In other words, scheduling optimization problems typically define an optimization function, which may minimize cost, maximize profit, or minimize total time. During the process of obtaining the solution, the optimization algorithm searches for a solution that minimizes (or maximizes) the value of the optimization function; this is the optimal solution.

[0040] Decision variables are the key parameters that determine the solution to an optimization problem. For example, in a scheduling problem, decision variables might be how tasks are assigned to machines, or the start and end times of tasks. The values ​​of these variables directly affect the scheduling optimization results.

[0041] In contrast, the aforementioned infeasibility diagnostic information can be information output by the solver to explain the reasons for the infeasibility of the target problem model data when the scheduling model has logical contradictions (such as the solution being interrupted due to constraint conflicts) or no feasible solution. For example, it can generate "Constraint 1 conflicts with constraint 3, and job J2 cannot avoid resource conflicts of machine M1 while satisfying priority constraints, resulting in no feasible solution".

[0042] Step S43: Based on the solution results, determine the feasibility status of the target problem model data to obtain a logically consistent and solvable scheduling problem.

[0043] It is easy to understand that the above-mentioned feasibility status can be used to describe whether the target problem model data is logically consistent and whether there is a feasible solution. It can include two cases: "feasible" and "infeasible". The feasibility status can be determined based on the solution results of the solver.

[0044] At this point, if the generating device obtains the output of the above-mentioned optimal target value and key decision variables, the feasibility status of the target problem model data can be determined as "feasible", and the scheduling problem corresponding to the target problem model data can be directly classified as a logically consistent and solvable scheduling problem. If infeasibility diagnosis information is obtained, the feasibility status is determined as "infeasible", and it is necessary to return to the previous constraint enhancement processing step, adjust the additional constraints (such as deleting conflicting constraints, modifying constraint parameters, etc.), regenerate the target problem model data, and perform feasibility verification again until a feasible scheduling problem is obtained.

[0045] Therefore, this embodiment achieves automated solution and verification of the model by converting the target problem model data into executable code, avoiding the tediousness and inefficiency of manual verification. Based on the output infeasibility diagnostic information or the corresponding optimal solution's key feasibility information, logical contradictions and problems in the model can be discovered in a timely manner. Finally, based on the judgment of feasibility status, this embodiment ensures that the final output scheduling problem is logically consistent and solvable, improving the reliability and practicality of the scheduling problem, avoiding the use of invalid models, saving computing resources and time, and thus providing a high-quality problem set for the testing and evaluation of scheduling optimization algorithms.

[0046] It should be understood that the solver code described above may be unstable, leading to inaccurate solution results and thus unreliable feasibility verification results, resulting in low generalizability of scheduling problem data. Therefore, in a feasible implementation, this embodiment may further include steps S44-S45 after step S42: Step S44: Perform multidimensional verification of the scheduling problem through a multidimensional majority voting mechanism; the multidimensional majority voting mechanism includes a cross-language model voting mechanism, a single-language model multi-sample voting mechanism, and an execution-level voting mechanism for executing the same solver code multiple times; Step S45: Based on the verification results of the multidimensional verification, determine the integration feasibility verification result of the scheduling problem.

[0047] Understandably, the aforementioned multidimensional majority voting mechanism can refer to a mechanism that verifies the solution to the scheduling problem from multiple dimensions. Its purpose is to determine the final solution verification result by comprehensively considering the voting results from different dimensions, i.e., the verification result of the aforementioned multidimensional verification, so as to improve the reliability and accuracy of the scheduling problem and verify the integration feasibility of the scheduling problem.

[0048] In this embodiment, the multidimensional majority voting mechanism includes, but is not limited to, three dimensions: cross-language model voting mechanism, single-language model multi-sample voting mechanism, and execution-level voting mechanism.

[0049] The cross-language model voting mechanism can be a verification mechanism that uses multiple different language models (such as GPT-5, Claude, and Gemini) to generate corresponding executable code for the same scheduling problem. This mechanism votes on multiple solutions output by different models and selects the most frequent, consistent result as the verification result for that dimension. For example, if model A outputs an optimal target value of 12 hours, model B outputs an optimal target value of 12 hours, and model C outputs an optimal target value of 13 hours, and in the above example, 12 hours appears twice and 13 hours appears once, the cross-language model voting result is 12 hours.

[0050] The multi-sample voting mechanism for single-language models can be a verification mechanism that generates multiple executable code samples for a single language model by adjusting parameters in the generation scheduling problem (such as adjusting temperature parameters in the low-temperature generation process or adding different cue perturbations). This mechanism allows running code samples with different parameters to obtain multiple solution results, and then performs cluster analysis on these results. The solution result corresponding to the largest consistent result cluster (i.e., the cluster containing the most results) is selected as the verification result for that dimension. For example, if 7 code samples have a solution result of 12 hours, 2 code samples have a solution result of 11 hours, and 1 code sample has a solution result of 13 hours, then the largest consistent result cluster is 12 hours, and the verification result for that dimension can be 12 hours.

[0051] Finally, the execution-level voting mechanism can be a verification mechanism that executes the same executable code generated from the same language model multiple times (e.g., 5 times) by controlling the random seed and resetting the cache to eliminate accidental mutations. This mechanism can obtain multiple solution results generated after multiple executions, vote on these results, and select the consistent result as the verification result for that dimension. For example, if all 5 execution results are consistent (e.g., all are 12 hours), then the execution-level voting result is the consistent result; if there are inconsistencies (e.g., 3 times are 12 hours, 2 times are 12.5 hours), then it can be re-executed multiple times (e.g., increased to 10 times), and the result with the most occurrences can be selected as the verification result for that dimension.

[0052] At this point, the aforementioned integrated feasibility verification result can refer to the verification result of judging the feasibility of the scheduling problem by comprehensively considering the verification results of different dimensions in the multi-dimensional majority voting mechanism, in order to verify whether the scheduling problem has higher reliability and accuracy. For each scheduling problem, the generative model can first use the multi-sample voting mechanism of a single-language model to generate multiple outputs and select the most consistent result. During execution, an execution-level voting mechanism that executes the same solver code multiple times ensures the consistency of the initialization state and random seed in each execution, ensuring the stability of the output. Finally, a cross-language model voting mechanism is used to generate the final solution result from the candidate results of multiple large language models.

[0053] At this point, if the verification results across the three dimensions are consistent (e.g., all within 12 hours), the integrated feasibility verification result is this consistent result, and the scheduling problem is deemed feasible. If two dimensions show consistent results and one dimension shows a different result, the consistent result across the two dimensions is taken as the integrated verification result. If all three dimensions show different results, the scheduling problem or language model generation process needs to be re-examined, anomalies eliminated, and multi-dimensional voting verification performed again until a clear integrated feasibility verification result is obtained. Therefore, this embodiment can ultimately determine the feasibility status of the calling problem based on the integrated verification result.

[0054] In this implementation, the complementarity of different language models can be utilized through a cross-language model voting mechanism to reduce the impact of the bias of a single model on the results; multiple samples can be generated through a single-language model multi-sample voting mechanism to reduce the randomness and uncertainty in the model generation process and improve the consistency of the results; and the same code can be executed multiple times through an execution-level voting mechanism to eliminate the impact of accidental mutations on the results and ensure the stability of the results.

[0055] In summary, this embodiment first constructs a hierarchical knowledge representation structure to provide a systematic and standardized knowledge foundation for generating scheduling problems corresponding to the target scheduling domain, ensuring the accuracy and consistency of terminology. Then, based on the hierarchical knowledge representation structure, a semantic planning process is performed to generate intermediate description schemes for standardized elements of the corresponding scheduling problem, providing a clear basis for subsequent processing. Simultaneously, this embodiment can systematically add constraints and standardize constraint naming through constraint enhancement processing, making the generated target problem model data closer to the actual scenario. Finally, this embodiment can ensure the logical consistency and solvability of the finally generated scheduling problem through feasibility verification. Therefore, the overall scheduling problem generation scheme proposed in this embodiment achieves automated and scalable generation of scheduling problems, improving the reliability and usability of the generated scheduling problems.

[0056] This embodiment provides a method for generating scheduling problems. The method includes: constructing a hierarchical knowledge representation structure for the target scheduling domain, the hierarchical knowledge representation structure comprising a general concept layer and an instance data layer; performing semantic planning based on the hierarchical knowledge representation structure to generate an intermediate description scheme for the corresponding scheduling problem; performing constraint enhancement processing based on the intermediate description scheme to generate target problem model data; converting the target problem model data into executable code, the executable code including variable definitions, optimization functions, and constraint information; executing the executable code and obtaining the solution results, the solution results including feasibility key information or infeasibility diagnostic information; determining the feasibility status of the target problem model data based on the solution results, thereby obtaining a logically consistent and solvable scheduling problem. The overall scheduling problem generation scheme proposed in this embodiment can achieve automated and scalable generation of scheduling problems, improving the reliability and usability of the generated scheduling problems.

[0057] Furthermore, this embodiment discloses a multi-dimensional verification of the scheduling problem using a multi-dimensional majority voting mechanism. This mechanism includes a cross-language model voting mechanism, a multi-sample voting mechanism for a single-language model, and an execution-level voting mechanism for multiple executions of the same solver code. Based on the verification results of the multi-dimensional verification, the integrated feasibility verification result of the scheduling problem is determined. By integrating the voting results from three dimensions, this embodiment ensures that the obtained integrated feasibility verification result has extremely high reliability and accuracy, effectively avoiding misjudgments caused by a single model, a single sample, or a single execution. This further ensures that the final generated scheduling problem is logically consistent and solvable, providing a more reliable foundation for the testing and evaluation of scheduling optimization algorithms.

[0058] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0059] It is easy to understand that existing methods for generating scheduling problems lack systematic knowledge support, resulting in inconsistent terminology and illogical logic in the generated scheduling problems. Furthermore, it is difficult to combine general scheduling theory with specific practical scenarios, making the generated scheduling problems easily disconnected from actual applications, and their applicability needs to be improved.

[0060] Therefore, based on the first embodiment, please refer to Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the scheduling problem generation method of this application. In this embodiment, step S10 includes steps S11 to S14: Step S11: Obtain a predefined glossary of scheduling theories and actual scheduling scenario data corresponding to the target scheduling domain; It is easy to understand that the scheduling problem generation process in this embodiment can be divided into three stages: knowledge base, semantic planning, and hybrid synthesis. For ease of understanding, refer to... Figure 3 To illustrate, Figure 3 This is a schematic diagram illustrating the process of the second embodiment of the scheduling problem generation method of this application. Figure 3 As shown, in the knowledge foundation stage, a predefined scheduling theory vocabulary and actual scheduling scenario data of the target calling domain can be obtained, and different graph structures can be generated based on this, namely the subsequent general concept layer and instance data layer.

[0061] The aforementioned predefined scheduling theory glossary can be a set of general theoretical terms predefined from theoretical research results and practical experience in the field of target scheduling, obtained through literature review, industry practice summary, etc., and forms the basis for constructing the general concept layer in this embodiment. This glossary includes common target types (such as minimizing project duration, minimizing work-in-process inventory, etc.) and constraint categories (such as non-preemptive constraints, resource capacity constraints, etc.) in this field. The aforementioned actual scheduling scenario data can be derived from real data in specific scheduling application scenarios within the target scheduling domain, including job information, machine information, priority relationships between jobs, resource constraints, and other data in that scenario. This data forms the basis for constructing the instance data layer in this embodiment.

[0062] Step S12: Construct a general concept layer based on the scheduling theory vocabulary. The general concept layer includes target type nodes and constraint category nodes related to the scheduling problem in the target scheduling domain. It should be understood that, in this embodiment, the aforementioned general concept layer and instance data layer can be independent graph structures constructed based on the scheduling theory vocabulary of the target scheduling domain and actual scheduling scenario data, respectively.

[0063] The general concept layer can construct graph nodes based on the acquired scheduling theory vocabulary, with target type and constraint category as the core, and each node corresponding to a standard term. Therefore, the target type nodes can be core graph nodes in the general concept layer used to represent the optimization target type of the scheduling problem, such as Minimize Makespan and Minimize Tardiness; while the constraint category nodes can be core graph nodes in the general concept layer used to represent the category of constraints in the scheduling problem, such as Set Partitioning and Logical Condition. Finally, the generation device can connect related target type nodes and / or constraint category nodes through edges to form the graph network structure of the general concept layer. Therefore, this embodiment can provide a standardized terminology reference for subsequent scheduling problem generation by encoding a general vocabulary of scheduling theory through the general concept layer, avoiding the introduction of non-standard terms.

[0064] Step S13: Construct an instance data layer based on the actual scheduling scenario data. The instance data layer includes entity nodes and their associations related to the preset scheduling scenario in the target scheduling domain. Understandably, the aforementioned entity nodes can be core elements in the instance data layer, used to represent specific objects in the actual scheduling scenario, such as job identifiers (J1, J2, etc.) and machine sets (M1, M2, etc.). The relationships can be the logical connections between entity nodes in the instance data layer, such as the priority relationship between jobs (J1 must be executed before J2), the allocation relationship between machines and jobs, etc., which can be specifically represented as edges between different entity nodes.

[0065] At this point, the generation device can first clean and organize the collected actual scheduling scenario data, removing redundant data and erroneous information. Then, using the cleaned jobs and machines as entity nodes, and the priority relationships between jobs and the adaptation relationships between machines and jobs as edges, a graph structure for the instance data layer is constructed. For example, if the actual data includes jobs J1, J2, and J3, and machines M1 and M2, and J1 needs to be executed before J2, then nodes J1, J2, J3, M1, and M2 are created in the instance data layer, and an edge from J1 to J2 is created to represent the priority relationship. Furthermore, in this embodiment, the instance data layer can be dynamically constructed by exporting data from graph databases such as Neo4j, ensuring the accuracy and real-time nature of the data.

[0066] Step S14: Associatively map the general concept layer and the instance data layer to generate a hierarchical knowledge representation structure.

[0067] It is easy to understand that this embodiment can perform association mapping through the correspondence between nodes in the general concept layer and the instance data layer. This process must ensure that the entities and relationships in the instance data layer can be explained and standardized by the theoretical knowledge of the general concept layer, that is... Figure 3 The parameters shown are valid for forced execution.

[0068] For example, the priority relationship between jobs J1 and J2 in the instance data layer corresponds to the "logical condition" constraint category node in the general concept layer; the scheduling objective "minimize the total completion time of J1, J2, and J3" corresponds to the "MinimizeMakespan" objective type node in the general concept layer. Furthermore, if the data defines three jobs {J1, J2, J3} and two machines {M1, M2}, and J1 has a higher priority than J2, these entities will be encoded as graph nodes and edges. Subsequent generated target problem model data must only reference these valid identifiers; non-existent jobs such as J4 or machine M3 will be automatically excluded.

[0069] Therefore, this embodiment ensures global semantic integrity based on the general concept layer and guarantees local factual accuracy based on the instance data layer. Together, they constitute a protective framework that ensures all subsequent steps operate based on clearly defined and consistent inputs—a hierarchical knowledge representation structure. This embodiment uses this associative mapping to allow the specific data in the instance data layer to be standardized and interpreted by the theoretical knowledge of the general concept layer, thereby forming a structurally complete and logically consistent hierarchical knowledge representation structure.

[0070] Understandably, when the extraction of core elements of a scheduling problem relies on manual operation, it is inefficient and prone to omissions or errors; moreover, the lack of standardized element representation formats in existing element analysis processes makes it difficult to effectively utilize these elements in subsequent processing, affecting the efficiency and accuracy of scheduling problem generation. Therefore, in a feasible implementation, in this embodiment, step S20 may include steps S21-S23: Step S21: Serialize the instance data layer to obtain structured text description information; It should be noted that, as Figure 3 As shown, before semantic planning based on a preset language model, the generation device can first convert the structured graph data (nodes and edges) in the instance data layer into linear text description information that is easy for the language model to process, that is, perform the above-mentioned serialization process, and this process must completely preserve the entity information and relationships in the instance data layer.

[0071] For example, the generation device can employ a custom serialization algorithm to traverse the graph structure of the instance data layer, converting the attributes of each entity node (such as job number, processing time, machine number, processing capacity, etc.) and the relationships between nodes (such as priority relationships, adaptation relationships, etc.) into natural language text descriptions. For instance, for nodes J1 (processing time is 5 hours), J2 (processing time is 3 hours), and the priority edge from J1 to J2, the serialized text description is: "There is a job J1 with a processing time of 5 hours; job J2 with a processing time of 3 hours; job J1 has a higher priority than J2 and must be completed before J2 starts processing." The serialized text must completely and accurately reflect the core information of the instance data layer to facilitate understanding by the language model.

[0072] Step S22: Input the general concept layer and the text description information into a preset language model for semantic planning to obtain standardized problem elements, which include problem description, objective function and constraint list; Understandably, the aforementioned preset language model can be a pre-selected and configured large language model (such as GPT-4, Gemini, etc. LLM (Large Language Model)) with natural language processing and logical reasoning capabilities, used to perform semantic analysis and planning on the input knowledge (i.e., general concept layer and text description information) and extract standardized problem elements.

[0073] At this point, the standardized problem elements can be the core elements of the scheduling problem with a unified format and standardized expression obtained after processing by a preset language model. These elements may include the problem description (a clear description of the scheduling scenario and requirements), the objective function (including type and context, the type must be consistent with the node name of the general concept layer), and the list of constraints (each constraint includes type and context).

[0074] For example, the generating device can input the serialized text description information along with knowledge from the general concept layer (such as a list of target type nodes and a list of constraint category nodes) into a preset language model. Simultaneously, a preset prompt is provided to the preset language model. The prompt could be: "Based on the provided scheduling theory knowledge (general concept layer) and actual scenario data (serialized text), extract standardized scheduling problem elements, including a problem description, an objective function (including type and context; the type must be completely consistent with the node names in the general concept layer), and a list of constraints (each constraint includes type and context; the type must be completely consistent with the node names in the general concept layer)." Then, the preset language model can perform semantic analysis and logical reasoning based on the input knowledge and prompt to extract the standardized problem elements. For example, the type of the objective function might be determined as "MinimizeMakespan," with the context being "minimize the total completion time of jobs J1, J2, and J3 on machines M1 and M2"; the constraint list might include a constraint of type "LogicalCondition," with the context being "job J1 must complete processing before J2 begins."

[0075] Step S23: Generate an intermediate description scheme for the corresponding scheduling problem based on the standardized problem elements.

[0076] In essence, the generation device organizes the standardized problem elements extracted from the language model according to a preset JSON format, obtaining an intermediate description scheme in JSON blueprint format. This JSON blueprint integrates two layers of knowledge: a general concept layer ensures the correctness of terminology for objective functions and constraint names, while an instance data layer provides factual details such as job identifiers, machine sets, and priority relationships. This results in a clear and accurate intermediate description scheme, simplifying the complexity of the original graph structure (i.e., the general concept layer and the instance data layer) and providing a reliable and machine-readable foundation for future hybrid synthesis stages.

[0077] For example, the fields in the above JSON format may include "problem_description" (stores a problem description), "objective" (stores the objective function, including "type" and "context" subfields), and "constraints" (stores a list of constraints, each constraint being an object with "type" and "context" subfields). The value of the objective function's type field must exactly match the node name in the general interpretation layer; that is, the user-inputted type value in "objective" must be a standard node name defined in the general interpretation layer (such as MinimizeMakespan or SetPartitioning). In this case, the specific format of the intermediate description scheme can be as follows: #JSON format { "problem_description": "There are jobs J1, J2, and J3, and machines M1 and M2. The jobs need to be assigned to machines for processing, satisfying the priority constraints between jobs, and minimizing the total completion time." “objective”: { "type": "MinimizeMakespan"; “context”: “Minimize the total completion time of jobs J1, J2, and J3 on machines M1 and M2”; }, "constraints": [ { "type": "LogicalCondition"; “context”: “Job J1 must be completed before J2 begins”; }, { "type": "ResourceConstraint"; “context”: “Each machine can only process one job at a time”; } ] } Therefore, the intermediate description scheme generated in this application presents the core elements of the scheduling problem in a structured manner, providing clear and standardized input for subsequent constraint enhancement processing. This implementation can convert the graph data of the instance data layer into text that can be processed by a language model through serialization, achieving effective knowledge transfer; and utilize a preset language model for semantic planning, automatically extracting standardized problem elements from the general interpretation layer and text data, improving the efficiency and accuracy of element extraction, and avoiding the subjectivity and errors of manual operation; finally, a standardized JSON format is used to generate the intermediate description scheme, ensuring the uniformity and standardization of element representation, facilitating the automated execution of subsequent constraint enhancement processing steps, and providing a guarantee for the efficient advancement of the entire scheduling problem generation process.

[0078] In one feasible implementation, step S30 may include steps S31 to S34: Step S31: Extract the structural elements of the intermediate description scheme to generate a standard static title; Understandably, the aforementioned standard static title can be a fixed-format title containing problem information, naming conventions (such as terminology usage rules), and function descriptions. This embodiment can clearly define the core background and optimization direction of the target problem model data based on the standard static title. Its content can be directly extracted from the intermediate description scheme, including key problem elements such as problem description, constraint list, and objective function, and then structured.

[0079] For example, the generation device can extract the content of the "problem_description" field from the intermediate description scheme as the problem information part of the scheduling problem in the standard static title; based on the terminology rules of the general concept layer, it can extract the "constraints" field from the intermediate description scheme to formulate the naming convention part in the standard static title, such as "all constraint names must adopt the constraint category node names defined in the general concept layer". At this time, the generation device can extract the key parameter "constraint['type']" for each constraint item in the JSON format intermediate description scheme, that is, each constraint in the above constraint list, as a reference for the subsequent generation of standard node names by the preset language model; and extract the content of the "objective" field from the intermediate description scheme as the function description part of the standard static title.

[0080] Then, the generating device integrates these three parts to form a standard static title, such as: "Problem information: There are existing jobs J1, J2, J3 and machines M1 and M2. The jobs need to be assigned to machines for processing to meet the priority constraints between jobs and minimize the total completion time; Naming convention: All constraint names must be consistent with the constraint category node names in the general concept layer; Function description: MinimizeMakespan (Minimize the total completion time of jobs J1, J2, J3 on machines M1 and M2)."

[0081] Step S32: Perform naming normalization on the additional constraints to be added to obtain standard constraint names; It is easy to understand that the aforementioned naming standardization process refers to the process by which the generation device standardizes the names of additional constraints to be added according to a preset terminology standard (i.e., the names of nodes in the general concept layer of the hierarchical knowledge representation structure), ensuring that the name of each new constraint added by the preset language model to the intermediate description scheme is accurate, unique, and conforms to industry standards. In this case, the aforementioned standard constraint name can be the constraint name obtained by the preset language model after naming standardization for each additional constraint to be added to the intermediate description scheme. This name strictly matches the constraint category node names in the general concept layer of the hierarchical knowledge representation structure, thereby ensuring the accuracy and consistency of terminology.

[0082] It is important to understand that the naming of existing constraints lacks effective control, and language models are prone to generating non-standard and inconsistent constraint names, leading to terminology confusion and affecting the readability, interpretability, and solver's analytical efficiency. Furthermore, non-standard terminology may prevent effective comparison and reuse between different models, reducing the reproducibility of research results. Therefore, in a feasible implementation, in this embodiment, step S32 may include steps A1-A2: Step A1: Construct a term constraint space based on the hierarchical knowledge representation structure; It is easy to understand that the aforementioned term constraint space can be a set of terms constructed by the generating device with the constraint category node names of the general concept layer in the hierarchical knowledge representation structure as the core. This space can define the unique legal range of constraint naming and ensure the standardization of constraint names.

[0083] For example, the generating device can traverse the general concept layer in the hierarchical knowledge representation structure, extract the names of all constraint category nodes (such as SetPartitioning, LogicalCondition, ResourceConstraint, TimeConstraint, etc.), and then combine these names into a set, namely the term constraint space.

[0084] Step A2: Using the graph constraint log processor, the naming scope of the additional constraints to be added is restricted to the term constraint space to obtain standard constraint names.

[0085] It is important to understand that the aforementioned Graph Constrained Logits Processor can be a lexical control tool based on graph structure and log processing mechanism. It can intercept and filter the generated tokens in real time during the process of generating constraint names by the preset language model, allowing the preset language model to select only legal terms from the term constraint space as constraint names.

[0086] For example, the generating device can first encode all constraint category node names in the term constraint space into prefix tree (Trie tree) paths using a tokenizer to construct a Trie tree structure, which can quickly determine whether the generated token belongs to a valid term.

[0087] Then, as the preset language model iteratively adds additional constraints to the basic problem data corresponding to the intermediate description scheme, the generating device can intercept and process the additional constraints output by the preset language model in real time through the graph constraint log processor.

[0088] At this point, for each newly generated constraint token, the graph constraint log processor can query the pre-built Trie tree based on the term constraint space to determine whether the constraint token is a prefix or the full name of a constraint name in the term constraint space. If the token is not on the current branch of the Trie tree, i.e., it is not part of a valid term, the Logits value of the token is set to -inf, preventing it from being selected for output by the preset language model. If the token is part of a valid term, its Logits value is retained, allowing the preset language model to continue generating subsequent tokens until a complete standard constraint name is formed. For example, when processing the constraint condition "each machine can only process one job at a time," when the preset language model attempts to generate the constraint name for its corresponding additional constraint condition, the graph constraint log processor determines through the Trie tree that only "ResourceConstraint" is a valid name, thereby guiding the preset language model to generate this standard constraint name and avoiding the generation of non-standard names such as "MachineResourceLimit."

[0089] In this embodiment, a terminology constraint space is constructed to clarify the standard range of constraint naming, providing a basis for naming standardization. Simultaneously, a graph constraint log processor enables real-time interception and filtering at the token level, forcing the preset language model to generate only standard constraint names within the terminology constraint space when additional constraints are added. This fundamentally solves the problems of terminology confusion and non-standard naming, ensuring the accuracy, consistency, and standardization of constraint names. Therefore, this embodiment improves the readability and interpretability of the scheduling model through the use of standard constraint names, facilitating rapid resolution by the solver. It also provides convenience for comparison and reuse between different scheduling models, enhancing the reproducibility and promotional value of the research results.

[0090] Step S33: Generate a mathematical model description that can be executed by the solver based on the constraint context in the constraint list and the standard constraint name; Step S34: Generate target problem model data based on the standard static title, the standard constraint name, and the mathematical model description.

[0091] It should be noted that the generation device can extract the key parameter "constraint['context']" from the constraint list as the context for the subsequent generation of LaTeX formulas and textual explanations by the preset language model, i.e., the aforementioned constraint context. The mathematical model description can be a detailed description of the constraints, including mathematical formulas in LaTeX format and concise textual explanations. This data model description can be recognized and parsed by the solver to accurately reflect the mathematical expression and practical meaning of the constraints.

[0092] In this embodiment, the token restriction can be removed during the process of generating mathematical model descriptions based on constraint context. Specifically, this implementation can employ a strategy of first constraining and then detailing the mathematical model. First, in the constraint phase, a trie can be used at the token level to force the pre-defined language model to select only standard terms from the terminology constraint space corresponding to the knowledge graph as pre-defined names, ensuring absolute terminology accuracy. Then, in the detailing phase, the token restriction can be removed, allowing the pre-defined language model to freely generate complex LaTeX formulas and textual explanations using its pre-trained language capabilities, thereby providing flexible and natural mathematical expressions and achieving a balance between terminology accuracy and expressive flexibility.

[0093] At this point, the generation device can input each constraint that has undergone naming normalization, namely the standard constraint name and the content of the corresponding "constraint['context']" field in the intermediate description scheme (as the constraint context), into the preset language model, and provide the corresponding preset mathematical model prompts to the preset language model.

[0094] For example, the preset mathematical model prompt could be: "Based on the constraint name 'Standard Constraint Name' and the context 'Constraint Context', generate: 1. An accurate LaTeX format mathematical formula; 2. A concise textual explanation of the effect of the constraint. Do not repeat the constraint name or number; only use the formula and explanation to answer."

[0095] Then, the pre-defined language model can generate a corresponding mathematical model description based on the input information and its own mathematical knowledge. For example, for the standard constraint name "LogicalCondition" and the constraint context "Job J1 must be completed before J2 starts", the generated mathematical formula might be "S_{J2}\geqC_{J1}" (where S_{J2} represents the start time of job J2 and C_{J1} represents the completion time of job J1), which can be interpreted as "This constraint ensures that the start time of job J2 is not earlier than the completion time of job J1, satisfying the priority requirement between job J1 and J2".

[0096] At this time, as Figure 3 As shown, the final generated target problem model data can be a complete problem model data that integrates the standard static title, the standard constraint name of each additional constraint generated by the graph constraint log processor, the constraint list obtained from the intermediate description scheme, and the generated mathematical model description. At this point, the target problem model data can be presented in the form of a structured (i.e., JSON format) document.

[0097] Understandably, to avoid the "illusion" of inaccurate terminology often arising from the pursuit of text fluency in existing large language models, this embodiment employs a hybrid generation method of "locking terminology first, then writing formulas." This fully leverages the complementary advantages of symbolic control and neural generation, ensuring that the generated target problem model data is not only accurate in terminology and structure but also possesses mathematical rigor and practical application value. Therefore, the target problem model data generated in this embodiment can completely and accurately present all the key information of the scheduling model, providing high-quality input for subsequent feasibility verification.

[0098] In this implementation, generating standard static titles clarifies the core background and optimization direction of the scheduling model, providing clear guidance for understanding the model and subsequent processing. Simultaneously, standardized naming ensures the accuracy and consistency of constraint names, improving the model's readability and interpretability. Automated generation of mathematical model descriptions through a language model enhances the accuracy and efficiency of mathematical formula generation, avoiding errors from manual writing. The integration of target problem model data makes the scheduling model's information complete and structured, facilitating solver analysis and feasibility verification, further improving the reliability and practicality of scheduling problem generation.

[0099] This embodiment discloses the following steps: First, a predefined scheduling theory vocabulary and actual scheduling scenario data corresponding to the target scheduling domain are obtained. A general concept layer is constructed based on the scheduling theory vocabulary, including target type nodes and constraint category nodes related to the scheduling problem in the target scheduling domain. Second, an instance data layer is constructed based on the actual scheduling scenario data, including entity nodes related to the preset scheduling scenario in the target scheduling domain and their associated relationships. Third, the general concept layer and the instance data layer are mapped to generate a hierarchical knowledge representation structure. The instance data layer is serialized to obtain structured text description information. Fourth, the general concept layer and the text description information are input into a preset language model for semantic planning to obtain standardized problem elements, including a problem description, objective function, and constraint list. Fifth, an intermediate description scheme for the corresponding scheduling problem is generated based on the standardized problem elements. The intermediate description scheme undergoes element structure extraction to generate a standard static title; a terminology constraint space is constructed based on a hierarchical knowledge representation structure; a graph constraint log processor restricts the naming scope of additional constraints to be added to the terminology constraint space, resulting in standard constraint names; a solver-executable mathematical model description is generated based on the constraint context in the constraint list and the standard constraint names; and target problem model data is generated based on the standard static title, standard constraint names, and mathematical model description. This embodiment provides a standardized scheduling theory terminology system by constructing a general concept layer, ensuring the accuracy and consistency of terminology in subsequent scheduling problem generation and effectively avoiding common terminology confusion and errors in unconstrained generation. The construction of the instance data layer allows scheduling problem generation to be rooted in specific real-world scenarios, ensuring the generated problems have practical significance. Finally, by combining general theory with actual data through association mapping, the hierarchical knowledge representation structure possesses both theoretical depth and practical applicability, providing a reliable knowledge foundation for subsequent semantic planning, constraint enhancement, and other steps, further enhancing the rationality and practicality of the generated scheduling problems.

[0100] For example, to help understand the technical concept or principle of the scheduling problem generation method after combining this embodiment with the above-described Embodiments 1 and 2, please refer to Figure 4 , Figure 4 A simplified schematic diagram of the scheduling problem generation method of this application is shown below: Compared to traditional scheduling problem generation methods that rely on manual design or random instance generation, this application utilizes a structured and scalable mechanism to automatically encode, filter, and verify constraints and objectives, ensuring the feasibility and logical consistency of the generated scheduling problems. Simultaneously, this application systematically encodes constraints, objective functions, and their logical relationships into a knowledge graph, thereby selecting, combining, and expanding constraints according to unified standards. This effectively avoids the generation of conflicting and infeasible problem model data, ultimately achieving the goal of batch generating diverse and realistic scheduling instances, ensuring scalability while improving interpretability and usability.

[0101] Therefore, as Figure 4 As shown, this application, based on a knowledge graph-driven multi-agent framework, automates the generation of scheduling problems through three progressive stages: Phase 1: Constructing the basic problem by extracting the problem type, main constraints, and objective function from the knowledge graph: At this point, the generation device can first collect relevant knowledge in the target scheduling domain (such as flow shop scheduling, job shop scheduling, etc.), including a recognized scheduling theory vocabulary (such as target types, constraint categories, etc.) and actual scheduling scenario data (such as specific job information, machine information, priority relationships between jobs, etc.). Based on the scheduling theory vocabulary, a general concept layer is constructed. This layer stores target types (such as minimizing project duration, minimizing delay, etc.) and constraint categories (such as set partitioning, logical conditions, etc.) in the form of nodes. Based on the actual scheduling scenario data, an instance data layer is constructed. This layer stores entities such as jobs and machines in the form of nodes, and stores the relationships between entities in the form of edges (such as priority relationships between jobs). Subsequently, an association mapping is performed between the general concept layer and the instance data layer to ensure that the entities and relationships in the instance data layer correspond to the theoretical knowledge in the general concept layer, thus forming a complete hierarchical knowledge representation structure, i.e. Figure 4 The knowledge graph shown.

[0102] Then, the basic question generator in the generation device performs semantic planning based on the knowledge graph to generate intermediate description schemes, namely... Figure 4 The basic question is shown. At this point, the basic question generator can serialize the entity nodes and relationships in the instance data layer, converting them into structured text description information (such as "There are jobs J1, J2, and J3, machines M1 and M2, and job J1 has a higher priority than J2").

[0103] The basic question generator then inputs the textual description information along with knowledge from the general concept layer into a preset language model (such as the GPT series models, Claude, etc.). Preset prompts guide the language model in semantic planning, extracting standardized question elements, including a clear question description (corresponding to...). Figure 4The problem type), a clearly defined objective function (including type and context), and a list of constraints (including type and context for each constraint) (corresponding to...) Figure 4 (The main constraints). The basic problem generator then generates a structured JSON intermediate description scheme based on these standardized problem elements, where the "type" field must strictly follow the node names defined in the general concept layer.

[0104] Phase Two: Enhancing constraints by systematically adding secondary, additional constraints, a process guided by knowledge graph relationships: The constraint classifier and constraint adder in the generation device perform constraint enhancement processing. At this time, the constraint adder can extract the problem description, constraint list and objective function from the intermediate description scheme to generate a standard static title containing the problem description, naming convention and objective function.

[0105] Meanwhile, the constraint adder can construct a term constraint space based on the hierarchical knowledge representation structure during the process of adding additional constraints to the basic problem. Then, through the constraint classifier (i.e. the graph constraint log processor mentioned above), iteratively restricts the constraint naming range of the additional constraints generated by the preset language model to this term constraint space, ensuring that the constraint names of the generated additional constraints are standard constraint names.

[0106] Subsequently, the constraint adder takes the standard constraint names and constraint context obtained from the intermediate description scheme as input, guiding the preset language model to generate LaTeX-formatted mathematical formulas and concise textual explanations that can be executed by the solver. Finally, the standard static title, standard constraint names, constraint condition list, and corresponding mathematical model description are integrated to form the basic problem for adding additional constraints, namely the target problem model data mentioned above.

[0107] Phase 3: Verify the constraint order and feasibility to ensure that the final scheduling model is logically consistent and solvable. To verify the model's rationality, the model validator in the generation device can convert the target problem model data into Python code executable by the solver (such as Gurobi). This code must fully implement the variable definitions (such as decision parameters like task allocation method, task start and end times), objective function (such as code implementation for minimizing the project duration), and constraints (such as code implementation for resource constraints, time constraints, etc.) corresponding to the problem description.

[0108] The model validator can then execute the executable code to obtain the solution results. If the solver returns the optimal objective value and key decision variables, it indicates that the generated target problem model data is feasible; if it returns diagnostic information indicating infeasibility or no solution, it indicates that the target problem model data is infeasible. At this point, the generation device can determine the feasibility status of the target problem model data based on the solution results, ultimately obtaining a logically consistent and solvable scheduling problem.

[0109] In summary, this application combines knowledge graph reasoning with a multi-agent architecture to automate and scalably generate diverse scheduling problems. It also enhances the reliability of the generated scheduling problems by strengthening systematic constraints while maintaining logical consistency. Furthermore, this application verifies the feasibility of the target problem model data through solver-level verification, improving the interpretability and repeatability of the generated scheduling problems. This bridges the gap between theoretical research and practical applications, enhancing the applicability of the generated scheduling problems.

[0110] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the scheduling problem generation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0111] This application also provides a scheduling problem generation device, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the module structure of the scheduling problem generation device according to an embodiment of this application. In this embodiment, the scheduling problem generation device includes: The structure generation module T1 is used to construct a hierarchical knowledge representation structure for the target scheduling domain, wherein the hierarchical knowledge representation structure includes a general concept layer and an instance data layer. The scheme processing module T2 is used to perform semantic planning based on the hierarchical knowledge representation structure and generate an intermediate description scheme for the corresponding scheduling problem. Constraint module T3 is used to perform constraint enhancement processing based on the intermediate description scheme to generate target problem model data; Problem generation module T4 is used to perform feasibility verification on the target problem model data to obtain a logically consistent and solvable scheduling problem.

[0112] Optionally, in this embodiment, the structure generation module T1 is further configured to acquire a predefined scheduling theory vocabulary and actual scheduling scenario data corresponding to the target scheduling domain; construct a general concept layer based on the scheduling theory vocabulary, the general concept layer including target type nodes and constraint category nodes related to the scheduling problem in the target scheduling domain; construct an instance data layer based on the actual scheduling scenario data, the instance data layer including entity nodes and their associations related to the preset scheduling scenarios in the target scheduling domain; and perform association mapping on the general concept layer and the instance data layer to generate a hierarchical knowledge representation structure.

[0113] Optionally, in this embodiment, the scheme processing module T2 is further configured to perform serialization processing on the instance data layer to obtain structured text description information; input the general concept layer and the text description information into a preset language model for semantic planning to obtain standardized problem elements, the standardized problem elements including problem description, objective function and constraint list; and generate an intermediate description scheme for the corresponding scheduling problem based on the standardized problem elements.

[0114] Optionally, in this embodiment, the constraint module T3 is further configured to perform element structure extraction on the intermediate description scheme to generate a standard static title; perform naming normalization processing on the additional constraints to be added to obtain standard constraint names; generate a solver-executable mathematical model description based on the constraint context in the constraint list and the standard constraint names; and generate target problem model data according to the standard static title, the standard constraint names, and the mathematical model description.

[0115] Optionally, in this embodiment, the constraint module T3 is further configured to construct a term constraint space based on the hierarchical knowledge representation structure; and to restrict the naming scope of the additional constraints to be added to the term constraint space through the graph constraint log processor, thereby obtaining standard constraint names.

[0116] Optionally, in this embodiment, the problem generation module T4 is further configured to convert the target problem model data into executable code, the executable code including variable definitions, optimization functions and constraint information; execute the executable code and obtain the solution results, the solution results including feasibility key information or infeasibility diagnosis information; determine the feasibility status of the target problem model data based on the solution results, and obtain a logically consistent and solvable scheduling problem.

[0117] Optionally, in this embodiment, the problem generation module T4 is further configured to perform multidimensional verification of the scheduling problem through a multidimensional majority voting mechanism; the multidimensional majority voting mechanism includes a cross-language model voting mechanism, a single-language model multi-sample voting mechanism, and an execution-level voting mechanism for executing the same solver code multiple times; based on the verification results of the multidimensional verification, the integration feasibility verification result of the scheduling problem is determined.

[0118] The scheduling problem generation apparatus provided in this application, employing the scheduling problem generation method in the above embodiments, can solve the technical problem of how to improve the reliability and usability of the generated call problem data. Compared with the prior art, the beneficial effects of the scheduling problem generation apparatus provided in this application are the same as those of the scheduling problem generation method provided in the above embodiments, and other technical features in the scheduling problem generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0119] This application provides a scheduling problem generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the scheduling problem generation method in the first embodiment described above.

[0120] The following is for reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing the scheduling problem generation device of the embodiments of this application. The scheduling problem generation device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The scheduling problem generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0121] like Figure 6As shown, the scheduling problem generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the scheduling problem generation device. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the scheduling problem generating device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows scheduling problem generating devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0122] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, an embodiment disclosed in this application includes a scheduling problem generation program product, which includes a scheduling problem generation program carried on a computer-readable medium, the scheduling problem generation program containing program code for performing the methods shown in the flowcharts. In such an embodiment, the scheduling problem generation program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the scheduling problem generation program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0123] The scheduling problem generation device provided in this application, employing the scheduling problem generation method in the above embodiments, can solve the technical problem of how to improve the reliability and usability of the generated call problem data. Compared with the prior art, the beneficial effects of the scheduling problem generation device provided in this application are the same as those of the scheduling problem generation method provided in the above embodiments, and other technical features in this scheduling problem generation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0124] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0125] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0126] This application provides a storage medium having computer-readable program instructions (i.e., a scheduling problem generation program) stored thereon, which are used to execute the scheduling problem generation method in the above embodiments.

[0127] The storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of the storage medium may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0128] The aforementioned storage medium may be included in the scheduling problem generation device; or it may exist independently and not be assembled into the scheduling problem generation device.

[0129] The aforementioned storage medium carries one or more programs. When the aforementioned one or more programs are executed by the scheduling problem generation device, the scheduling problem generation device is thus generated.

[0130] The scheduling problem generation program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0132] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0133] The readable storage medium provided in this application is a storage medium that stores computer-readable program instructions (i.e., a scheduling problem generation program) for executing the above-described scheduling problem generation method, and can solve the technical problem of how to improve the reliability and usability of the generated calling problem data. Compared with the prior art, the beneficial effects of the storage medium provided in this application are the same as the beneficial effects of the scheduling problem generation method provided in the above embodiments, and will not be repeated here.

[0134] The above are only some embodiments of this application and do not limit the scope of the solution of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A method for generating scheduling problems, characterized in that, The method includes: A hierarchical knowledge representation structure for the target scheduling domain is constructed, which includes a general concept layer and an instance data layer. Based on the hierarchical knowledge representation structure, semantic planning is performed to generate an intermediate description scheme for the corresponding scheduling problem. Constraint enhancement processing is performed based on the intermediate description scheme to generate target problem model data; The feasibility of the target problem model data is verified to obtain a logically consistent and solvable scheduling problem.

2. The scheduling problem generation method as described in claim 1, characterized in that, The steps for constructing a hierarchical knowledge representation structure for the target scheduling domain include: Acquire a predefined glossary of scheduling theories and actual scheduling scenario data corresponding to the target scheduling domain; A general concept layer is constructed based on the aforementioned scheduling theory vocabulary, and the general concept layer includes target type nodes and constraint category nodes related to scheduling problems in the target scheduling domain; An instance data layer is constructed based on the actual scheduling scenario data. The instance data layer includes entity nodes and their associated relationships related to the preset scheduling scenario in the target scheduling domain. The general concept layer and the instance data layer are associated and mapped to generate a hierarchical knowledge representation structure.

3. The scheduling problem generation method as described in claim 2, characterized in that, The step of performing semantic planning based on the hierarchical knowledge representation structure to generate an intermediate description scheme for the corresponding scheduling problem includes: The instance data layer is serialized to obtain structured text description information; The general concept layer and the text description information are input into a preset language model for semantic planning to obtain standardized problem elements, which include a problem description, an objective function, and a list of constraints. Based on the standardized problem elements, an intermediate description scheme for the corresponding scheduling problem is generated.

4. The scheduling problem generation method as described in claim 3, characterized in that, The step of performing constraint enhancement processing based on the intermediate description scheme to generate target problem model data includes: The intermediate description scheme is subjected to element structure extraction to generate a standard static title; The additional constraints to be added are named in a standardized manner to obtain standard constraint names; A mathematical model description executable by the solver is generated based on the constraint context in the constraint list and the standard constraint names. The target problem model data is generated based on the standard static title, the standard constraint name, and the mathematical model description.

5. The scheduling problem generation method as described in claim 4, characterized in that, The step of normalizing the naming of the additional constraints to be added to obtain standard constraint names includes: A term constraint space is constructed based on the hierarchical knowledge representation structure; By using the graph constraint log processor, the naming scope of the additional constraints to be added is restricted to the term constraint space to obtain standard constraint names.

6. The scheduling problem generation method as described in claim 1, characterized in that, The step of verifying the feasibility of the target problem model data to obtain a logically consistent and solvable scheduling problem includes: The target problem model data is converted into executable code, which includes variable definitions, optimization functions, and constraint information. The executable code is executed and the solution results are obtained, including feasible key information or infeasibility diagnostic information. Based on the solution results, the feasibility status of the target problem model data is determined, resulting in a logically consistent and solvable scheduling problem.

7. The scheduling problem generation method as described in claim 6, characterized in that, After determining the feasibility status of the target problem model data based on the solution results, and obtaining a logically consistent and solvable scheduling problem, the process further includes: The scheduling problem is verified in multiple dimensions through a multi-dimensional majority voting mechanism; the multi-dimensional majority voting mechanism includes a cross-language model voting mechanism, a multi-sample voting mechanism for a single-language model, and an execution-level voting mechanism for executing the same solver code multiple times. Based on the verification results of the multidimensional verification, the integration feasibility verification results of the scheduling problem are determined.

8. A scheduling problem generation device, characterized in that, The device includes: The structure generation module is used to construct a hierarchical knowledge representation structure for the target scheduling domain, wherein the hierarchical knowledge representation structure includes a general concept layer and an instance data layer. The scheme processing module is used to perform semantic planning based on the hierarchical knowledge representation structure and generate an intermediate description scheme for the corresponding scheduling problem. The constraint module is used to perform constraint enhancement processing based on the intermediate description scheme to generate target problem model data; The problem generation module is used to perform feasibility verification on the target problem model data to obtain a logically consistent and solvable scheduling problem.

9. A scheduling problem generation device, characterized in that, The device includes: a memory, a processor, and a scheduling problem generation program stored in the memory and executable on the processor, the scheduling problem generation program being configured to implement the steps of the scheduling problem generation method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a scheduling problem generation program, which, when executed by a processor, implements the steps of the scheduling problem generation method as described in any one of claims 1 to 7.

Images