A SWAT watershed hydrological model task planning system, method and product

Abstract

The application relates to the technical field of hydrology and water resources simulation, and discloses a SWAT watershed hydrology model task planning system, method and product, which comprises a knowledge graph construction module, an embedded index construction module, a query coding and two-stage retrieval module, a context construction module and a large language model task planning module. Through the complete planning process of knowledge graph modeling, vector index construction, two-stage retrieval, context generation and structured task output, the whole-process intelligentization from a user's natural language demand to SWAT watershed hydrology model executable task planning is realized, the SWAT file / parameter structure can be accurately matched, the professionalism, accuracy and executability of task planning are improved, and the problems of high operation threshold, large artificial workload, unstable and unexecutable output of a general large model of a traditional SWAT watershed hydrology model are solved.

Description

Technical Field

[0001] This invention relates to the field of hydrological and water resources simulation technology, specifically to a SWAT watershed hydrological model task planning system, method, and product. Background Technology

[0002] SWAT watershed hydrological models are a class of physical process models widely used for watershed hydrological and water environment simulation. They typically describe watershed topography, meteorology, land use, management measures, and other information through a series of input configuration files, parameter files, and output result files, and output spatiotemporal variations in runoff, sediment, and nutrients. Traditionally, the configuration and analysis of SWAT watershed hydrological models relied heavily on researchers or engineers manually consulting model documentation, input / output manuals, and extensive textual materials, combining experience to select appropriate files and parameters for modification or analysis. This process was labor-intensive, had a high barrier to entry, and was prone to errors.

[0003] With the imminent widespread adoption of intelligent agents, embedding the SWAT watershed hydrological model into water resources and water environment intelligent agents can solve many problems. However, the challenge lies in how to enable large models to plan a task chain that can accurately invoke and execute the SWAT watershed hydrological model.

[0004] The SWAT watershed hydrological model is a complex physical process model. Its modeling task is essentially a complex task chain that spans files, parameters, and processes. For example: modifying the land use scenario → modifying the HRU file parameters; performing nitrogen load analysis → reading the RCH output file and locating the TN variable → calling the water quality submodule; running the scenario simulation → ensuring that the dependencies between FILE.CIO, .bsn, .mgt, .rte, and .sub files are correct. The generation of these task chains is not a natural language question-and-answer question, but requires the large model to: (1) understand the SWAT file structure (dozens of files, hundreds or thousands of parameters); (2) identify the scope of parameter application (spatial and temporal scale, applicable modules, whether it is related to the scenario); (3) correctly reason "user needs → model process → files and parameters that need to be read / modified"; (4) output an executable task step chain.

[0005] However, general large models themselves do not possess professional knowledge in the SWAT field. They cannot deeply understand the complex file system of SWAT watershed hydrological models, nor can they accurately determine the file to which each parameter belongs, the physical process relationship between variables, and the module dependency relationship. This directly leads to unstable, unstructured, and unexecutable model output content, and even problems such as specifying non-existent files, incorrectly modifying irrelevant parameters, and violating the model's operating logic. They are completely unable to perform accurate and reliable SWAT modeling task planning.

[0006] Therefore, in complex process simulation scenarios such as the SWAT watershed hydrological model, there is an urgent need for a task planning method that can construct the files, parameters, and relationships of the SWAT watershed hydrological model into a computable knowledge graph, and combine it with embedding retrieval and a large language model to achieve a method that can understand the user's natural language needs, outputs that are precisely aligned with SWAT files / parameters, and has good executability. Summary of the Invention

[0007] This invention provides a SWAT watershed hydrological model task planning system, method, and product to solve the problem of how to construct a computable knowledge graph from the files, parameters, and relationships of the SWAT watershed hydrological model in complex process simulation scenarios, and how to achieve a task planning system that can both understand the user's natural language needs and output tasks that are precisely aligned with SWAT files / parameters and have good executability through embedding retrieval and combining with a large language model.

[0008] In a first aspect, the present invention provides a SWAT watershed hydrological model task planning system, which is connected to a user terminal; the system includes: a knowledge graph construction module, an embedded index construction module, a query encoding and two-stage retrieval module, a context construction module, and a large language model task planning module; the knowledge graph construction module is connected to the embedded index construction module, the query encoding and two-stage retrieval module, and the context module respectively; the embedded index construction module and the query encoding are connected to the two-stage retrieval module; the context module is connected to the query encoding and two-stage retrieval module and the large language model task planning module respectively; The module consists of four parts: a knowledge graph construction module, a knowledge graph construction module, and a context construction module. The knowledge graph construction module acquires domain knowledge sources for the SWAT watershed hydrological model and constructs a knowledge graph file based on these sources. The embedded index construction module generates file-level and parameter-level compressed index files based on the knowledge graph file. The query encoding and two-stage retrieval module processes the natural language task description received from the user, based on the file-level and parameter-level compressed index files, and establishes a target mapping structure. This target mapping structure reflects the correspondence between File entity IDs and Parameter entity IDs in the SWAT watershed hydrological model. The context construction module generates target entity JSON text based on the target mapping structure and the knowledge graph file. The large language model task planning module acquires the target large language model, inputs the target entity JSON text and the natural language task description into the target large language model, obtains the SWAT watershed hydrological model's task planning JSON, and sends the task planning JSON to the user.

[0009] The SWAT watershed hydrological model task planning system provided by this invention, through a knowledge graph construction module, enables structured entity modeling of SWAT watershed hydrological model files and parameters, providing a professional domain semantic and structural foundation for subsequent retrieval and task planning, and facilitating standardized knowledge storage and retrieval. Furthermore, by embedding an index construction module, entities are transformed into searchable vectors and compressed indexes are generated, achieving high-fidelity vectorization of entity semantics, providing an efficient data carrier for online retrieval, and improving retrieval response efficiency. Further, by using query encoding and a two-stage retrieval module to process the natural language task descriptions sent by the user and establishing a target mapping structure, accurate matching of user needs with SWAT entities is achieved, reducing retrieval noise and improving the matching degree and interpretability of retrieval results with the SWAT file structure. Furthermore, by using a context construction module, parsable entity contexts for large language models can be generated, helping to avoid logical errors caused by empirical reasoning in large language models. Finally, by using a large language model task planning module, natural language requirements are transformed into structured SWAT task planning JSON, realizing the transformation of user intent into an executable task chain, thereby enabling the output results to be directly parsed and executed by downstream tools. Therefore, by implementing this invention, the entire process from user natural language requirements to executable task planning for the SWAT watershed hydrological model is made intelligent. It can accurately match the SWAT file / parameter structure, improve the professionalism, accuracy and executability of task planning, and solve the problems of high operation threshold, large amount of manual work and unstable and unexecutable output of general large model in traditional SWAT watershed hydrological models.

[0010] In one optional implementation, the knowledge graph construction module includes: an acquisition submodule, an extraction submodule, and a construction submodule, wherein the extraction submodule is connected to the acquisition submodule and the construction submodule, respectively. The module is divided into three submodules: Acquisition, Extraction, and Construction. The Acquisition submodule is used to acquire domain knowledge sources from the SWAT watershed hydrological model; Extraction submodule is used to extract domain knowledge sources to obtain multiple File entities, multiple Parameter entities, and multiple entity relationships; and Construction submodule is used to construct a knowledge graph file based on the multiple File entities, multiple Parameter entities, and multiple entity relationships.

[0011] The SWAT watershed hydrological model task planning system provided by this invention extracts multiple File entities, multiple Parameter entities, and multiple entity relationships from the precisely acquired SWAT watershed hydrological model domain knowledge source. This achieves accurate extraction of the core entities and relationships of the SWAT watershed hydrological model, clarifies the entity hierarchy and membership, and preserves the model's topological structure features. Furthermore, the extracted entities and relationships are converted into JSON format knowledge graph files, realizing the structured and standardized organization of domain knowledge, facilitating subsequent module calls and parsing.

[0012] In one alternative implementation, the embedded index building module includes: an entity text generation submodule and an embedded computing and storage submodule, which are connected. The entity text generation submodule is used to serialize the JSON structures of multiple File entities and multiple Parameter entities in the knowledge graph file to obtain the JSON text of multiple File entities and multiple Parameter entities respectively; the embedded computation and storage submodule is used to generate file-level compressed index files and parameter-level compressed index files based on the JSON text of multiple File entities and multiple Parameter entities.

[0013] The SWAT watershed hydrological model task planning system provided by this invention serializes the entity JSON structure through an entity text generation submodule, fully preserving all semantic information such as the entity's ID, attributes, and type. This achieves high-fidelity conversion of SWAT entity semantics and provides accurate input for vectorization encoding. Furthermore, by embedding a computation and storage submodule, the serialized entity text is converted into a compressed index file, realizing vectorized and indexed storage of entities. This provides efficient and callable vector data for online retrieval, avoids redundant calculations, and improves system operating efficiency.

[0014] In one optional implementation, an embedded computing and storage submodule includes: a vectorization unit, a creation unit, a generation unit, and an encapsulation unit, wherein the creation unit is connected to the vectorization unit, the generation unit, and the encapsulation unit, respectively, and the generation unit and the encapsulation unit are connected. The vectorization unit is used to vectorize and encode multiple File entity JSON texts and multiple Parameter entity JSON texts using a preset equal-sentence vector model, respectively, to obtain multiple File entity vectors and multiple Parameter entity vectors; the building unit is used to build a file embedding matrix based on multiple File entity vectors, and a parameter embedding matrix based on multiple Parameter entity vectors; the generation unit is used to generate an array of File entity IDs based on the file embedding matrix, and an array of Parameter entity IDs based on the parameter embedding matrix; the encapsulation unit is used to encapsulate the array of File entity IDs and the file embedding matrix to obtain a file-level compressed index file, and to encapsulate the array of Parameter entity IDs and the parameter embedding matrix to obtain a parameter-level compressed index file.

[0015] The SWAT watershed hydrological model task planning system provided by this invention converts entity text into fixed-length vectors through vectorization units, realizing the semantic vectorization of SWAT entities. This allows entities to be retrieved through vector similarity, achieving precise semantic matching. Furthermore, by establishing a unit-constructed file / parameter embedding matrix, a structured organization of entity vectors is achieved, establishing a one-to-one correspondence between vectors and entities, providing structured data for similarity calculation. Further, by generating an entity ID array with the same row order as the embedding matrix through a generation unit, and establishing a mapping relationship between vectors and entity IDs, rapid conversion of retrieval results to entity IDs is achieved. Finally, by encapsulating the entity ID array and embedding matrix into a compressed index file through a packaging unit, compressed storage of vector data is achieved, reducing disk usage while ensuring efficient data loading and parsing.

[0016] In one alternative implementation, the embedded computing and storage submodule is further configured to, when the knowledge graph file undergoes an update that meets preset requirements, regenerate a new file-level compressed index file and a new parameter-level compressed index file based on the knowledge graph file.

[0017] The SWAT watershed hydrological model task planning system provided by this invention regenerates compressed index files when the knowledge graph is updated, realizing a dynamic update mechanism for embedded indexes. This enables the system to adapt to the updates and iterations of SWAT watershed hydrological model knowledge, ensuring the timeliness and accuracy of the index files. It also ensures that the task planning results of the entire system are always consistent with the latest SWAT file / parameter system, thereby improving the maintainability and scalability of the system.

[0018] In one optional implementation, the query encoding and two-stage retrieval module includes: a loading submodule, an encoding submodule, a first calculation and determination submodule, a first determination submodule, a second calculation and determination submodule, and a building submodule; the loading submodule is connected to the encoding submodule, the first calculation and determination submodule, the first determination submodule, and the second calculation and determination submodule; the encoding submodule is connected to the first calculation and determination submodule and the second calculation and determination submodule; the first determination submodule is connected to the first calculation and determination submodule and the second calculation and determination submodule; and the building submodule is connected to the first calculation and determination submodule and the second calculation and determination submodule. The module is divided into several submodules: a loading submodule, which loads a file-level compressed index file and a parameter-level compressed index file upon receiving a natural language task description from the user, and determines the File entity ID array, the file embedding matrix, the Parameter entity ID array, and the parameter embedding matrix; an encoding submodule, which encodes the natural language task description using a pre-defined sentence vector model to obtain a query vector; a first calculation and determination submodule, which calculates multiple first similarity values ​​between the query vector and each File entity vector in the file embedding matrix, and determines multiple target File entity IDs in the File entity ID array based on these first similarity values; a first determination submodule, which determines the Parameter entity subsets corresponding to the multiple target File entity IDs based on multiple entity relationships in the knowledge graph file, and determines the parameter embedding submatrix in the parameter embedding matrix based on the Parameter entity subsets; a second calculation and determination submodule, which calculates multiple second similarity values ​​between the query vector and each Parameter entity vector in the parameter embedding submatrix, and determines multiple target Parameter entity IDs in the Parameter entity ID array based on these second similarity values; and a building submodule, which builds a target mapping structure based on the multiple target File entity IDs and the multiple target Parameter entity IDs.

[0019] The SWAT watershed hydrological model task planning system provided by this invention effectively reduces retrieval noise and improves the accuracy and interpretability of retrieval results by employing a hierarchical retrieval strategy of coarse file screening and fine parameter screening, combined with the topological constraints of the SWAT watershed hydrological model. It achieves accurate mapping of user natural language requirements to specific SWAT files / parameters, solving the problems of excessively coarse retrieval granularity and low alignment with SWAT file structure in existing technologies.

[0020] In one alternative implementation, the context building module includes: a second determining submodule and a processing submodule, the second determining submodule and the processing submodule being connected; The second determination submodule is used to determine multiple original File entities and multiple original Parameter entities in the knowledge graph file based on the target mapping structure; the processing submodule is used to serialize the JSON structure of the multiple original File entities and the JSON structure of the multiple original Parameter entities respectively, and determine the JSON text of the target entity.

[0021] The SWAT watershed hydrological model task planning system provided by this invention has a second determination submodule that accurately retrieves original entities from a knowledge graph based on a target mapping structure, ensuring the completeness and accuracy of the acquired entities and providing reliable entity data for context generation. Furthermore, the processing submodule serializes the original entity JSON structure and generates target entity JSON text, fully preserving all entity attributes and semantic information. This allows for the generation of a structured context that a large language model can directly parse, avoiding inference errors caused by missing information in the large language model. Therefore, by implementing this invention, a precise conversion from a target mapping structure to a structured knowledge context is achieved, ensuring that the knowledge context contains complete semantic and structural information of SWAT entities. This provides accurate and comprehensive professional knowledge support for the large language model, constrains the model's inference space, and improves the accuracy of task planning.

[0022] In one optional implementation, the large language model task planning module includes: a prompt generation submodule and a task planning generation submodule, wherein the prompt generation submodule and the task planning generation submodule are connected. The prompt generation submodule is used to configure prompt constraints on the preset large language model using a preset prompt template to obtain the target large language model. The task planning generation submodule is used to input the natural language task description and the target entity JSON text into the target large language model, generate the task planning JSON of the SWAT watershed hydrological model that conforms to the predefined structure, and output the task planning JSON to the user terminal.

[0023] The SWAT watershed hydrological model task planning system provided by this invention constrains and configures the large language model through preset prompt templates, determining the model's role and output requirements. This avoids unstructured outputs that do not meet SWAT operation requirements and constrains the model's reasoning direction and output format. Furthermore, the task planning generation submodule inputs natural language requirements and knowledge context into the model and generates structured task planning JSON, realizing the transformation from user intent to an executable SWAT task chain. The output results are then precisely bound to SWAT files / parameters, allowing for direct parsing and execution by downstream tools. This improves the feasibility of task planning and provides a foundation for the automated operation of SWAT watershed hydrological models.

[0024] Secondly, the present invention provides a SWAT watershed hydrological model task planning method, used in the SWAT watershed hydrological model task planning system of the first aspect or any corresponding embodiment thereof; the method includes: The process involves: acquiring the domain knowledge source of the SWAT watershed hydrological model and constructing a knowledge graph file based on it; generating file-level compressed index files and parameter-level compressed index files based on the knowledge graph file; processing the natural language task description sent by the user based on the file-level and parameter-level compressed index files and establishing a target mapping structure, which reflects the correspondence between File entity IDs and Parameter entity IDs in the SWAT watershed hydrological model; generating target entity JSON text based on the target mapping structure and the knowledge graph file; acquiring the target large language model and inputting the target entity JSON text and the natural language task description into the target large language model to obtain the task planning JSON of the SWAT watershed hydrological model; and sending the task planning JSON to the user.

[0025] The SWAT watershed hydrological model task planning method provided by this invention realizes the entire process from SWAT domain knowledge modeling to user-end acquisition of structured task planning JSON. It solves the problems of large workload, high threshold, and error-proneness in traditional SWAT watershed hydrological model configuration and analysis, as well as the inability of general large models to reliably generate SWAT task planning chains. It improves the intelligence, accuracy, and executability of SWAT watershed hydrological model task planning, and realizes efficient planning and operation of SWAT watershed hydrological models under natural language interaction.

[0026] Thirdly, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the SWAT watershed hydrological model task planning method provided in the second aspect above. Attached Figure Description

[0027] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0028] Figure 1 This is a structural block diagram of the SWAT watershed hydrological model task planning system according to an embodiment of the present invention; Figure 2 This is a structural block diagram of a knowledge graph construction module according to an embodiment of the present invention; Figure 3This is a structural block diagram of the embedded index building module according to an embodiment of the present invention; Figure 4 This is a structural block diagram of the query encoding and two-stage retrieval module according to an embodiment of the present invention; Figure 5 This is a structural block diagram of the context building module according to an embodiment of the present invention; Figure 6 This is a structural block diagram of the large language model task planning module according to an embodiment of the present invention; Figure 7 This is a flowchart illustrating the SWAT watershed hydrological model task planning method according to an embodiment of the present invention. Figure 8 This is a flowchart of a large language model task planning based on SWAT model knowledge graph enhancement according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the two-stage SWAT model knowledge graph retrieval process according to an embodiment of the present invention; Figure 10 This is a task planning example diagram according to an embodiment of the present invention; Figure 11 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0031] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0032] The general large model lacks professional knowledge, making it difficult to understand the SWAT watershed hydrological model file system, accurately determine which file the parameters belong to, and accurately represent the physical process relationships between variables. This results in unstable, unstructured, and unexecutable output, as well as giving incorrect paths, such as modifying non-existent files or parameters.

[0033] Therefore, relying solely on large language models cannot reliably generate SWAT task planning chains; domain knowledge graphs are needed to provide constraints, structure, and semantic foundations. Domain knowledge graphs can provide model structure, thereby constraining the reasoning space of large models, ensuring that large models do not make logical errors or rely on guesswork based on experience; (2) translating vague user intentions into specific files and parameters. However, this knowledge must come from the explicitly defined relationships of the graph. Therefore, the two must be combined to assist large models in constructing task chains.

[0034] Furthermore, with the development of Large Language Models (LLM), modeling assistance solutions based on natural language interaction have emerged, such as using general large language models to answer questions in the SWAT manual and provide textual explanations of model results. These solutions typically employ a retrieval augmented generation (RAG) framework based on document fragments: first, the documentation is segmented and encoded into vectors; then, several relevant paragraphs are retrieved based on the user's question, and these are concatenated into the large language model's prompts, which then generate answers or suggestions.

[0035] In addition, there are some general technical solutions for enhancing large language models based on knowledge graphs. For example, domain knowledge can be constructed into a knowledge graph in the form of entity-relationship, and the entity description text can be encoded into vectors. Relevant entities can be retrieved for user questions and attached to the context of the large language model in order to improve the professionalism and consistency of the answers.

[0036] Furthermore, related technologies provide a method for assisting in the configuration / analysis of large language models based on knowledge graphs and embedding retrieval. Its typical process is as follows: 1. Construct domain knowledge into entities and relations, and encode entity text descriptions into vectors; 2. Encode the user's natural language question and retrieve the most similar entities or document fragments in the vector space at once; 3. The search results are appended to the LLM prompts in text form, and the LLM generates answers or solutions.

[0037] Compared to the general LLM+RAG method, hydrological mechanism model task planning has three core challenges: 1. Lack of precise alignment with the SWAT file / parameter structure.

[0038] Existing solutions typically treat entities as general concepts (such as rivers, precipitation, and nitrogen load) and do not model the input and output files and parameters within those files in SWAT as entities. This results in search results that cannot accurately locate specific files and parameter fields, making it difficult to directly guide users in performing file-level and parameter-level operations in SWAT projects.

[0039] 2. The SWAT watershed hydrological model has a strong topological structure, while the current retrieval granularity is too coarse and lacks graph structure constraints.

[0040] Existing technologies often employ one-time vector retrieval, directly selecting a number of similar items across all entities without utilizing topological relationships such as file-parameter relationships for hierarchical and constraint methods. This can easily lead to retrieved parameters that are relevant to the user's needs but belong to unrelated files; the hierarchical and dependency relationships between different entities cannot be reflected during the retrieval process, causing difficulties in understanding subsequent LLM (Local Management Model).

[0041] 3. Large language model outputs lack an executable, structured form.

[0042] Existing knowledge graph augmented LLMs typically output natural language descriptions or semi-structured text, lacking structured task planning results such as JSON with fixed fields, tailored to the SWAT operation chain. Downstream task models cannot reliably parse these natural language outputs, nor can they leverage them to automatically load files, read parameters, or batch configure simulation tasks.

[0043] This invention provides a SWAT watershed hydrological model task planning system. By constructing a complete planning process including knowledge graph modeling, vector index construction, two-stage retrieval, context generation, and structured task output, it achieves intelligent full-process planning from user natural language requirements to executable task planning for the SWAT watershed hydrological model. It accurately matches the SWAT file / parameter structure, improves the professionalism, accuracy, and executability of task planning, and solves the problems of high operation threshold, large manual workload, and unstable and unexecutable output of general large models in traditional SWAT watershed hydrological models.

[0044] This embodiment provides a SWAT watershed hydrological model task planning system, such as... Figure 1 As shown, the SWAT watershed hydrological model task planning system 1 is connected to the user terminal 2 and includes: a knowledge graph construction module 3, an embedded index construction module 4, a query encoding and two-stage retrieval module 5, a context construction module 6, and a large language model task planning module 7.

[0045] Among them, the knowledge graph construction module 2 is connected to the embedded index construction module 3 and the context construction module 5 respectively; the embedded index construction module 4 and the query encoding are connected to the two-stage retrieval module 5; the context module 6 is connected to the query encoding, the two-stage retrieval module 5, and the large language model task planning module 7 respectively.

[0046] Optionally, the knowledge graph construction module 3 is used to obtain the domain knowledge sources of the SWAT watershed hydrological model and construct a knowledge graph file based on the domain knowledge sources.

[0047] Among them, such as Figure 2 As shown, the knowledge graph construction module 3 includes an acquisition submodule 31, an extraction submodule 32, and a construction submodule 33. Furthermore, the extraction submodule 32 is connected to both the acquisition submodule 31 and the construction submodule 33.

[0048] Furthermore, the SWAT (Soil and Water Assessment Tool) watershed hydrological model represents a type of physical process model widely used in watershed hydrology and water environment simulation. It is used to describe basic information such as topography, meteorology, land use, and management measures within the watershed, and to simulate and output the spatiotemporal changes of hydrological and water environment elements such as runoff, sediment, and nutrients.

[0049] Furthermore, the domain knowledge source represents all professional data sources used to construct the domain-specific knowledge graph for the SWAT watershed hydrological model, which may include data sources such as input / output manuals, configuration file templates, and sample projects.

[0050] In an optional embodiment, firstly, the domain knowledge source of the SWAT watershed hydrological model is obtained using the acquisition submodule 31.

[0051] Specifically, based on the professional attributes of the SWAT watershed hydrological model, by selectively collecting official / standard data that contain its document system, parameter definitions, and document-parameter relationships, we can ensure the authority and completeness of the data source and avoid incomplete entity / relationship extraction due to missing data.

[0052] Secondly, the extraction submodule 32 is used to extract domain knowledge sources, resulting in multiple File entities, multiple Parameter entities, and multiple entity relationships.

[0053] In one optional embodiment, multiple File entities represent an abstract modeling of all input files, output files, and intermediate files of the SWAT watershed hydrological model. Furthermore, each File entity corresponds to a specific SWAT file, which may include attributes such as filename, description, spatial / temporal scale, and data format.

[0054] In an optional embodiment, the Parameter entity provides an abstract model of all variables and parameter fields within each File entity of the SWAT watershed hydrological model, and may include attributes such as variable name, unit, physical meaning, column / location, etc.

[0055] In an optional embodiment, the multiple entity relationships are FILE_HAS_PARAMETER (file-parameter membership relationship), which is a directed relationship that represents the topological association between multiple File entities and multiple Parameter entities, used to clarify which File entity a certain Parameter entity specifically belongs to.

[0056] In an optional embodiment, by extracting the collected domain knowledge sources through the submodule 32, the system can extract multiple File and Parameter entities and their relationships from unstructured / semi-structured data to form a modelable SWAT watershed hydrological model, thereby enabling the transformation from raw data to basic elements of a knowledge graph.

[0057] For example, the domain knowledge source is traversed to identify all input, output, and intermediate files of the SWAT watershed hydrological model, and an independent File entity is created for each file. Then, the entity is assigned attributes such as file name, description, spatiotemporal scale, and data format according to the template, thereby forming an entity set containing all File entities, i.e., multiple File entities.

[0058] Furthermore, for each identified SWAT file, all its internal variables and parameter fields are parsed, and an independent Parameter entity is created for each parameter field. Then, according to the template, the entity is assigned attributes such as variable name, unit, physical meaning, column / position, etc., thereby forming an entity set containing all Parameter entities, i.e., multiple Parameter entities.

[0059] Furthermore, based on the membership descriptions of files and parameters in the domain knowledge source, each Parameter entity can be matched with its corresponding File entity, and a directed membership relationship of FILE_HAS_PARAMETER can be established. This will determine the association logic between the parameter and its corresponding file, and form multiple corresponding entity relationships.

[0060] Furthermore, if there is a need to expand relationships, logical / physical relationships between other entities can also be extracted simultaneously.

[0061] Finally, in submodule 33, a knowledge graph file is constructed based on multiple File entities, multiple Parameter entities, and multiple entity relationships.

[0062] In an optional embodiment, the extracted multiple File entities, multiple Parameter entities, and multiple entity relationships are organized and encapsulated according to the unified modeling specification of JSON format by the construction submodule 33, and a corresponding standardized knowledge graph file that can be directly called is generated, thereby realizing the structured, visual, and computable modeling of SWAT domain knowledge.

[0063] For example, all the obtained File entities and Parameter entities are uniformly stored in the graph.entities field of the knowledge graph JSON file, and each entity exists as an independent JSON object, retaining all its attributes.

[0064] Furthermore, all extracted entity relationships are uniformly stored in the graph.relationships field of the knowledge graph JSON file, and each relationship exists as an independent JSON object, thereby determining the associated source entity (such as the Parameter entity), target entity (such as the File entity), and relationship type (such as FILE_HAS_PARAMETER).

[0065] Furthermore, after completing the field encapsulation of entities and relationships, a complete JSON format knowledge graph file is generated, and the file is verified for integrity to ensure that all entities have corresponding attributes, all relationships are clearly associated with two entities, and there is no missing / erroneous modeling information. Finally, a knowledge graph file that can be directly called by downstream modules is output.

[0066] In an optional embodiment, the knowledge graph file can also be stored in a graph database or a relational database; the entity structure can add or trim certain attribute fields while maintaining the distinction between File and Parameter. For example, the FILE_HAS_PARAMETER entity can be explicitly represented as an edge entity, or features such as process type and hydrological path can be added to the Parameter entity.

[0067] Optionally, the embedded index building module 4 is used to generate file-level compressed index files and parameter-level compressed index files based on the knowledge graph files.

[0068] Among them, such as Figure 3 As shown, the embedded index building module 4 includes an entity text generation submodule 41 and an embedded calculation and storage submodule 42, and the entity text generation submodule 41 and the embedded calculation and storage submodule 42 are connected.

[0069] Furthermore, the file-level compressed index file is a persistent storage carrier for the vectorized results of File entities. It can be quickly loaded and parsed, and the mapping relationship between entity IDs and matrix row indices can be reconstructed through the ID array. The parameter-level compressed index file is a persistent storage carrier for the vectorized results of Parameter entities. After loading, the vector corresponding to the parameter entity can be quickly located, thereby providing accurate vector data support for parameter-level retrieval.

[0070] In an optional embodiment, the entity text generation submodule 41 is used to serialize the JSON structures of multiple File entities and multiple Parameter entities in the knowledge graph file respectively to obtain the JSON text of multiple File entities and the JSON text of multiple Parameter entities.

[0071] Based on the lossless serialization principle of JSON structured data, and following the rules of no pruning, no modification, and no escaping, File and Parameter entities stored in the knowledge graph as JSON objects are directly converted into stable string text. This ensures that the text contains all field information such as entity ID, type, attributes, and file name, unit, and physical meaning under the attributes, thereby guaranteeing that the embedding model can capture the complete semantic features of the entity.

[0072] At the same time, by using unified serialization rules, the format of all entity text can be made consistent, ensuring the consistency and comparability of subsequent vectorization encoding.

[0073] For example, from the JSON format knowledge graph file generated by the knowledge graph construction module, extract all the JSON structures of multiple File entities and multiple Parameter entities. Each entity is an independent JSON object containing core fields such as ID, type, and attributes.

[0074] Furthermore, for each extracted File and Parameter entity JSON structure, no fields are trimmed, rewritten, or modified, and all key-value pairs and hierarchical structures of the original JSON object are fully preserved.

[0075] Furthermore, a JSON serialization tool is used to directly convert the original JSON object of each entity into a string text, thereby generating a stable JSON string without escaping Chinese characters, avoiding the loss of Chinese semantics due to escaping, and finally outputting multiple File entity JSON texts and multiple Parameter entity JSON texts that correspond one-to-one with the original entities.

[0076] Furthermore, each text uniquely corresponds to a File / Parameter entity, and fully carries all the semantic information of that entity.

[0077] In an optional embodiment, the embedded computing and storage submodule 42 is used to generate a file-level compressed index file and a parameter-level compressed index file based on multiple File entity JSON texts and multiple Parameter entity JSON texts.

[0078] Among them, such as Figure 3 As shown, the embedded computing and storage submodule 42 includes: a vectorization unit 43, an establishment unit 44, a generation unit 45, and an encapsulation unit 46. The establishment unit 44 is connected to the vectorization unit 43, the generation unit 45, and the encapsulation unit 46, respectively, and the generation unit 45 and the encapsulation unit 46 are connected.

[0079] First, in vectorization unit 43, a preset equal sentence vector model is used to vectorize and encode multiple File entity JSON texts and multiple Parameter entity JSON texts respectively, resulting in multiple File entity vectors and multiple Parameter entity vectors.

[0080] In an optional embodiment, the preset equal-sentence vector model represents a set of pre-trained text embedding models based on Qwen3-Embedding-0.6B, which is a replaceable existing technology module. Specifically, this preset equal-sentence vector model can convert structured entity JSON text into fixed-length, high-fidelity semantic embedding vectors, and can map user natural language task descriptions to the same vector space, supporting similarity calculation between vectors.

[0081] Furthermore, in addition to Qwen3-Embedding-0.6B, it can also include similar models such as BERT, RoBERTa, or self-developed pre-trained sentence vector models in the field of watershed hydrology. This embodiment does not make specific limitations on this, as long as it can generate comparable vector representations of entity JSON and user questions.

[0082] In one optional embodiment, based on the contextual semantic representation principle of the Transformer encoder and combined with the fixed-length vector generation rules of pooling operations, the entity JSON text is segmented, contextual features are extracted, fixed-length aggregation is performed, and normalization is applied. This enables the generated vectors to accurately represent the complete semantic information of the entity, and entity vectors of the same type reside in the same vector space. Furthermore, it supports measuring the semantic matching degree between the entity and user needs through vector similarity. The complete semantic information may include attributes, identifiers, types, etc.

[0083] For example, the multiple File entity JSON texts and multiple Parameter entity JSON texts output by the entity text generation submodule 41 are respectively input into the preset sentence vector model, and then each entity JSON text is segmented and converted into a token sequence that the model can recognize.

[0084] Furthermore, the Transformer encoder of the model, i.e., a multi-layer self-attention network, extracts the contextual features of the token sequence and obtains the hidden state representation of each token. Further, pooling is performed using the last valid token to extract the vector corresponding to the last valid position of the attention_mask from the hidden state, and the variable-length token representations are aggregated into a fixed-length vector.

[0085] Furthermore, L2 normalization is performed on the fixed-length vectors so that they lie on the unit sphere, resulting in multiple File entity vectors and multiple Parameter entity vectors with a dimension of 1024. Each entity corresponds to a unique embedding vector.

[0086] Furthermore, the similarity metric can be replaced by cosine similarity or Euclidean distance, and the retrieval effect can be guaranteed through normalization or parameter adjustment.

[0087] Secondly, in the establishment unit 44, a file embedding matrix is ​​established based on multiple File entity vectors, and a parameter embedding matrix is ​​established based on multiple Parameter entity vectors.

[0088] In one optional embodiment, the fixed order of the entity list is used as the row index, and the fixed-length embedding vector of each entity is used as a row of the matrix, so that the row number of the matrix corresponds one-to-one with the entity, realizing the ordered storage of batch entity vectors, and supporting batch similarity operations at the matrix level, thereby improving retrieval efficiency.

[0089] For example, multiple File entity vectors are stacked row by row in the order of the File entity list to form a two-dimensional file embedding matrix with the shape of "number of File entities × 1024", and each row of the matrix uniquely corresponds to a File entity vector.

[0090] Furthermore, multiple Parameter entity vectors are stacked row by row in the order of the Parameter entity list to form a two-dimensional parameter embedding matrix with the shape of "number of Parameter entities × 1024", and each row of the matrix uniquely corresponds to a Parameter entity vector.

[0091] The order of the File entity list and the Parameter entity list follows the original fixed order of the File entity list and the Parameter entity list in the knowledge graph.

[0092] Then, in generation unit 45, an array of File entity IDs is generated based on the file embedding matrix, and an array of Parameter entity IDs is generated based on the parameter embedding matrix.

[0093] In one optional embodiment, based on the principle of one-to-one correspondence mapping, the IDs of the corresponding entities are extracted synchronously with the row order of the embedded matrix as the basis, so that the Nth element of the ID array corresponds to the Nth row of the embedded matrix and also corresponds to the Nth entity in the original entity list, thereby finally realizing the accurate mapping between entity ID, matrix row index and entity vector.

[0094] For example, following the row order of the file embedding matrix, the unique IDs of the corresponding File entities in each row are extracted sequentially, and all IDs are combined into a one-dimensional array of File entity IDs according to the extraction order. Furthermore, the array length is the same as the number of File entities.

[0095] Simultaneously, following the row order of the parameter embedding matrix, the unique IDs of the corresponding Parameter entities in each row are extracted sequentially, and all IDs are combined into a one-dimensional Parameter entity ID array in the extraction order. Furthermore, the array length is consistent with the number of Parameter entities.

[0096] Furthermore, by establishing a precise mapping between entity IDs and matrix row indices, there is no need to store an additional mapping table. This allows for rapid reconstruction of the mapping by traversing the ID array when loading the index file, reducing storage redundancy. Furthermore, after retrieving the matrix row indices, the corresponding entity IDs can be directly matched using the ID array, improving the parsing efficiency of the search results. Furthermore, ensuring that the order of the ID array, the embedding matrix, and the original entity list is completely consistent fundamentally avoids matching errors between entities and vectors, improving data reliability.

[0097] Finally, the encapsulation unit 46 is used to encapsulate the File entity ID array and the file embedding matrix to obtain a file-level compressed index file, and the Parameter entity ID array and the parameter embedding matrix are encapsulated to obtain a parameter-level compressed index file.

[0098] In one optional embodiment, the npz compression format is used to encapsulate the ID array and the embedding matrix into a single compressed file in the form of key-value pairs. This can reduce disk storage usage and ensure that the corresponding data can be quickly extracted by specifying a key during loading, thereby decoupling offline calculation results from online retrieval.

[0099] For example, the File entity ID array and the file embedding matrix are encapsulated as key-value pairs into a compressed file named file_embeddings.npz, which is a file-level compressed index file. Similarly, the Parameter entity ID array and the parameter embedding matrix are encapsulated as key-value pairs into a compressed file named parameter_embeddings.npz, which is a parameter-level compressed index file.

[0100] Furthermore, the two compressed index files can be stored together in the embedded index directory, which helps to facilitate online access for subsequent query encoding and the two-stage retrieval module 5.

[0101] Optionally, the embedded computing and storage submodule 42 is also used to regenerate a new file-level compressed index file and a new parameter-level compressed index file based on the knowledge graph file when the knowledge graph file is updated to meet preset requirements.

[0102] In one optional embodiment, the update types of the knowledge graph are divided into major updates that require index updates and minor adjustments that do not require index updates. The index regeneration process is triggered only when a major update occurs. That is, by reusing the original generation logic of the embedded index, the serialization, vectorization, matrix construction, ID array generation and encapsulation operations of the File / Parameter entities in the updated knowledge graph are re-executed. This ensures that the new index file completely matches the updated knowledge graph entity information, further ensuring that the vector data during online retrieval is synchronized with the latest domain knowledge and avoiding retrieval errors and task planning deviations caused by knowledge updates.

[0103] For example, the update status of the knowledge graph file can be monitored in real time or periodically to determine whether an update that meets preset requirements has occurred. Significant updates to the knowledge graph may include large-scale additions or deletions of File / Parameter entities, modifications to core entity attributes (such as filename, parameter units, and physical meaning), and adjustments to the FILE_HAS_PARAMETER core relationship.

[0104] Furthermore, minor modifications to text descriptions or non-core attributes will not trigger index regeneration.

[0105] Furthermore, if it is determined to be a major update that needs to be updated, the full set of multiple File entity JSON structures and multiple Parameter entity JSON structures are extracted from the updated knowledge graph file and used as the data source for generating the new index.

[0106] Furthermore, the original steps of generating the index by the embedded computing and storage submodule are fully reused. The entity text generation submodule 41 and the embedded computing and storage submodule 42 are called sequentially for the updated entity data to obtain the newly generated file-level compressed index file and parameter-level compressed index file.

[0107] Furthermore, the two newly generated compressed index files replace the original old index files embedded in the index directory, completing the index update. Subsequently, during query encoding and loading of the two-stage retrieval module 5, the updated index files can be directly called, thus achieving synchronization between the retrieved data and the latest knowledge graph.

[0108] Optionally, the query encoding and two-stage retrieval module 5 is used to process the natural language task description based on the file-level compressed index file and the parameter-level compressed index file when it receives the natural language task description sent by the user terminal 2, and to establish a target mapping structure.

[0109] Among them, such as Figure 4 As shown, the query encoding and two-stage retrieval module 5 includes: a loading submodule 51, an encoding submodule 52, a first calculation and determination submodule 53, a first determination submodule 54, a second calculation and determination submodule 55, and an establishment submodule 56.

[0110] Furthermore, the loading submodule 51 is connected to the encoding submodule 52, the first calculation and determination submodule 53, the first determination submodule 54, and the second calculation and determination submodule 55, respectively; the encoding submodule 52 is connected to the first calculation and determination submodule 53 and the second calculation and determination submodule 54, respectively; the first determination submodule 54 is connected to the first calculation and determination submodule 53 and the second calculation and determination submodule 55, respectively; and the establishment submodule 56 is connected to the first calculation and determination submodule 53 and the second calculation and determination submodule 55, respectively.

[0111] Furthermore, the target mapping structure is used to reflect the correspondence between File entity IDs and Parameter entity IDs in the SWAT watershed hydrological model.

[0112] First, upon receiving the natural language task description sent by the user, the loading submodule 51 loads the file-level compressed index file and the parameter-level compressed index file, and determines the File entity ID array, the file embedding matrix, the Parameter entity ID array, and the parameter embedding matrix.

[0113] In an optional embodiment, the parsing rules of npz files can be used to extract the stored entity ID array and embedding matrix from the pre-generated file-level and parameter-level compressed index files, ensuring that the restored data is completely consistent with the output of the embedding index construction stage. At the same time, the one-to-one correspondence between the ID array and the row order of the embedding matrix provides directly calculable vector data and entity ID matching basis for subsequent retrieval.

[0114] For example, the file-level compressed index file (file_embeddings.npz) and the parameter-level compressed index file (parameter_embeddings.npz) in the embedded index directory are loaded respectively.

[0115] Furthermore, the File entity ID array and file embedding matrix are parsed from the file-level compressed index file, and the Parameter entity ID array and parameter embedding matrix are parsed from the parameter-level compressed index file.

[0116] Second, the encoding submodule 52 uses a preset equal sentence vector model to encode the natural language task description to obtain the query vector.

[0117] In one optional embodiment, the same preset sentence vector model from the embedded index construction stage is reused (ensuring consistency of the vector space), and through the model's word segmentation, Transformer encoder context feature extraction, pooling, and normalization processes, the semantics of the user's natural language can be transformed into numerical fixed-length vectors, realizing the transformation of natural language semantics into vector features. This allows subsequent modules to measure the semantic matching degree between user needs and entities through vector similarity.

[0118] For example, by using a pre-defined sentence vector model, the unstructured natural language task description is transformed into a fixed-length query vector with the same dimension and space as the File / Parameter entity vector. This allows user requirements to be semantically matched with entities in the SWAT model through vector similarity calculation. The specific encoding process can be referred to in the vectorization encoding process of the vectorization unit 43 mentioned above, and will not be repeated here.

[0119] Third, in the first calculation and determination submodule 53, multiple first similarity values ​​are calculated between the query vector and each File entity vector in the file embedding matrix, and multiple target File entity IDs are determined in the File entity ID array based on the multiple first similarity values.

[0120] In one optional embodiment, in the embedding vector space of all File entities, the semantic matching degree between the query vector (user requirements) and each File entity vector is measured by similarity calculation. Then, Top-K filtering is performed based on the similarity ranking, and the most relevant File entities are selected. This can achieve coarse screening from all files to candidate files and conforms to the file-first retrieval strategy.

[0121] For example, in the file embedding matrix, the first similarity value between the query vector and each File entity vector in the matrix is ​​calculated. Since all vectors have been L2 normalized, the dot product is used as an equivalent calculation method for cosine similarity.

[0122] Furthermore, all the first similarity values ​​are sorted from high to low, and the row indices of the File entities corresponding to the top K_f similarity values ​​are selected. Then, the corresponding File entity IDs are matched in the File entity ID array according to the row indices, thus finally obtaining multiple target File entity IDs. Here, K_f is a preset positive integer from 3 to 10.

[0123] Fourth, in the first determining submodule 54, based on multiple entity relationships in the knowledge graph file, a subset of Parameter entities corresponding to multiple target File entity IDs is determined, and based on the subset of Parameter entities, a parameter embedding submatrix is ​​determined in the parameter embedding matrix.

[0124] In one optional embodiment, by utilizing the graph structure constraints of the knowledge graph, the parameter retrieval range is limited to the range of the Parameter entity corresponding to the target File entity. This can avoid interference from irrelevant parameters and ensure that the retrieval results are accurately aligned with the topological structure of the files and parameters in the SWAT model.

[0125] For example, based on the FILE_HAS_PARAMETER relationship in the knowledge graph file, all corresponding Parameter entities are matched for each target File entity ID, and then integrated to obtain a subset of Parameter entities.

[0126] Furthermore, the corresponding row index is matched in the Parameter entity ID array according to the Parameter entity subset, and then the corresponding row vector is extracted from the full parameter embedding matrix according to the matched row index, thus finally forming the corresponding parameter embedding submatrix.

[0127] Fifth, the second calculation and determination submodule 55 is used to calculate multiple second similarity values ​​of the query vector and each Parameter entity vector in the parameter embedding submatrix, and based on the multiple second similarity values, multiple target Parameter entity IDs are determined in the Parameter entity ID array.

[0128] In one optional embodiment, based on the coarse screening at the file level, a refined semantic similarity retrieval is performed on the Parameter entity corresponding to the target File entity, and the parameter entity most relevant to the user's needs is selected, thereby enabling accurate screening from all parameters of candidate files to core parameters.

[0129] For example, in the parameter embedding submatrix, a second similarity value is calculated between the query vector and each Parameter entity vector in the matrix. Here, the dot product is also used for equivalent cosine similarity calculation.

[0130] Furthermore, all second similarity values ​​are sorted from high to low. For each target File entity, the row indices corresponding to the top K_p similarity values ​​of the Parameter entity are selected. Then, the corresponding Parameter entity IDs are matched in the Parameter entity ID array according to the row indices, thus finally obtaining multiple target Parameter entity IDs corresponding to each target File entity ID. Here, K_p is a preset positive integer from 5 to 20.

[0131] Sixth, in submodule 56, a target mapping structure is established based on multiple target File entity IDs and multiple target Parameter entity IDs.

[0132] In one optional embodiment, the selected target File entity ID and the corresponding target Parameter entity ID are structurally associated to generate a target mapping structure that reflects their affiliation.

[0133] For example, a key-value pair target mapping structure is constructed according to the rule that a single target File entity ID is an independent key and its corresponding multiple target Parameter entity IDs are values ​​(in list form).

[0134] Optionally, the context building module 6 is used to generate target entity JSON text based on the target mapping structure and knowledge graph file.

[0135] Among them, such as Figure 5 As shown, the context building module 6 includes a second determining submodule 61 and a processing submodule 62. Furthermore, the second determining submodule 61 and the processing submodule 62 are connected.

[0136] In an optional embodiment, the second determining submodule 61 is used to determine multiple original File entities and multiple original Parameter entities in the knowledge graph file based on the target mapping structure.

[0137] Specifically, the target File entity ID and target Parameter entity ID carried in the target mapping structure are used to perform precise matching with the unique IDs of all entities in the knowledge graph file. Furthermore, since each entity in the knowledge graph file has a unique ID, the corresponding original entity can be directly located through the ID, thus ensuring that the retrieved entity is completely consistent with the search results, while also preserving all the original attributes and structural information of the entity.

[0138] For example, all target File entity IDs and the target Parameter entity IDs corresponding to each target File entity ID are parsed from the target mapping structure to form a set of entity IDs to be matched.

[0139] Furthermore, by traversing all entities stored in the graph.entities field of the knowledge graph file, the File entity ID and Parameter entity ID in the set of IDs to be matched are compared one by one with the unique IDs of the entities in the knowledge graph to accurately locate the entity object corresponding to each ID, thereby obtaining multiple original File entities and multiple original Parameter entities.

[0140] In an optional embodiment, the processing submodule 62 is used to serialize the JSON structures of multiple original File entities and multiple original Parameter entities respectively, and determine the JSON text of the target entity.

[0141] Specifically, the complete JSON structure of each original File entity and original Parameter entity is subjected to standardized serialization processing without field pruning or Chinese character escaping, and a stable JSON string corresponding to each entity is generated, while retaining the entity's ID, type, attributes, and all attribute fields.

[0142] Furthermore, the JSON strings of all serialized File and Parameter entities are integrated into a unified JSON list, which enables different types of entities to be combined in a standardized format, ensuring structural consistency.

[0143] Furthermore, the integrated JSON list is serialized into a complete string text, namely the target entity JSON text. This target entity JSON text can contain complete original information about all retrieved entities, and can therefore be directly used as the knowledge context input for the large language model, facilitating the final context generation.

[0144] Optionally, the large language model task planning module 7 is used to obtain the target large language model, input the target entity JSON text and natural language task description into the target large language model, obtain the task planning JSON of the SWAT watershed hydrological model, and send the task planning JSON to the user terminal 2.

[0145] Among them, such as Figure 6 As shown, the large language model task planning module 7 includes a prompt generation submodule 71 and a task planning generation submodule 72. Furthermore, the prompt generation submodule 71 and the task planning generation submodule 72 are connected.

[0146] In an optional embodiment, the prompt generation submodule 71 is used to configure prompt constraints on a preset large language model using a preset prompt template to obtain a target large language model.

[0147] The preset prompt template is a system prompt template customized for SWAT task planning.

[0148] Specifically, by injecting SWAT-specific task planning rules into a pre-defined large language model through structured preset prompt templates, the model can clearly understand its role, available input information (target entity JSON text), and the output specifications it must follow. Simultaneously, by leveraging the instruction-following capabilities of the large language model, the inference space of the general model is limited to the professional scope of the SWAT model file / parameter system. This ensures that the generated results align with the actual operational needs of the SWAT model, resolving the issues of lack of professional knowledge and non-standardized output in general large models.

[0149] For example, the core constraint content from a preset prompt template is injected into the system prompt position of a preset large language model. The core constraint information within the template may include: (1) Role setting: used to determine that the model is a task planning assistant based on the SWAT model knowledge graph, and to limit the professional positioning of the model; (2) Input field description: Explain the structure of the target entity JSON text input, which may include the meaning of fields such as entity ID, type, attributes, etc., as well as the reference of exclusive fields such as attributes.parent_file (such as the file to which the parameter belongs), so that the model can correctly parse the SWAT professional information in the target entity JSON text; (3) Output format constraints: These are used to require the model to output only valid JSON objects that conform to a predefined structure, and to inform the core fields that the JSON object must contain and the definitions and requirements of each field.

[0150] Furthermore, after completing the above-mentioned prompt constraint configuration, the preset large language model will have the exclusive capability of SWAT watershed hydrological model task planning, and thus become a target large language model that can directly handle SWAT-related task planning requirements.

[0151] In an optional embodiment, the task planning generation submodule 72 is used to input the natural language task description and target entity JSON text into the target large language model, generate the task planning JSON of the SWAT watershed hydrological model that conforms to the predefined structure, and output the task planning JSON to the user terminal 2.

[0152] Specifically, the SWAT-specific entity knowledge (file / parameter ID, attributes, membership, etc.) in the target entity's JSON text is used as the model's knowledge context. Combined with the user's natural language task description, this allows the target large language model to perform inference under professional knowledge constraints. Simultaneously, output format constraints are used to transform the model's inference results into predefined structured JSON objects, thereby achieving the transformation from natural language requirements and professional knowledge inference to structured, executable task planning, ensuring the professionalism, structure, and executability of the output results.

[0153] For example, the task planning and generation submodule 72 assembles the model input messages in a fixed format, namely the natural language task description, the target entity JSON text, and the target large language model, and divides the received input messages into two parts: system messages and user messages.

[0154] The system messages are preset prompt template content. For example, user messages are concatenated according to the template "[User Question] {Natural Language Task Description} + [Candidate Entities (JSON List)] {Target Entity JSON Text}", and an instruction to output only one valid task planning JSON object is attached.

[0155] Furthermore, the assembled input message is input into the target large language model. Then, the target large language model combines the prompt constraints and SWAT expertise in the target entity JSON text to reason about the user's needs and sort out the specific operation steps to complete the task. Further, the corresponding sorted specific operation steps are transformed into SWAT watershed hydrological model task planning JSON that conforms to the predefined structure, i.e., task planning JSON.

[0156] Furthermore, the task planning JSON includes at least five core fields: user_intent (summarizing core user needs), assumptions (model inference hypotheses), files (related File entity information), parameters (related Parameter entity information), and plan_steps (list of task steps). Each step in plan_steps is explicitly bound to the corresponding File entity ID and Parameter entity ID.

[0157] Furthermore, the task planning generation submodule 72 sends the structured task planning JSON generated by the target large language model as the final result to the user terminal 2, so that the user can directly refer to it for execution or downstream SWAT automation auxiliary tools / scripts can parse and execute it.

[0158] In one instance, a user asked: "Please help me analyze which year from 2012 to 2015 had the highest output of water, total nitrogen, and total phosphorus in the Heidingzi River basin?"

[0159] Furthermore, the prompt generation submodule 71 (preset prompt): calls the fixed system prompt template SYSTEM_PROMPT, in which the following is completed: ① the role is set as a task planning assistant based on the SWAT model knowledge graph; ② the input entity is explained as the original JSON swat_kg.json, the fields of which include id / type / attributes, and attributes.parent_file indicates the file to which the parameters belong; ③ the target structure and constraints of the output task planning JSON are given (only valid JSON rules, etc. must be output).

[0160] Furthermore, the candidate entity context that accompanies the prompts: the two-stage retrieval obtains the file candidates and their parameter candidates, and the context building module retrieves the original JSON from the knowledge graph by ID and serializes it into entities_json.

[0161] Furthermore, in this example, the task planning results show that the graph entities ultimately used by the model include file:OUTPUT.RCH and parameter param:OUTPUT.RCH:FLOW_OUT / TOTNkg / TOTPkg; among them, for example, the original entity JSON of param:OUTPUT.RCH:FLOW_OUT explicitly contains fields such as unit m³ / s, description, and parent_file="OUTPUT.RCH".

[0162] Furthermore, the final message assembly method for feeding into the large model is as follows: construct two messages: system: Place the above SYSTEM_PROMPT -user: Construct the following template: [User Question] {query} + [Candidate Entities (JSON List)] {entities_json}, and require that "only one valid task planning JSON object is output". - Output: The task planning JSON returned by the large model is as follows: "plan_steps": [ { "step_id": 1, "title": "Identifying the core output files and variables required for the analysis", "description": "First, it was determined that the OUTPUT.RCH file would be used as the primary data source, containing flow and nutrient output from the outlet section of the watershed. The focus was on three key variables: FLOW_OUT (outflow), TOTN kg (total nitrogen output), and TOTP kg (total phosphorus output)." "related_files": [ #The list of File entity IDs associated with each step precisely points to the specific file in the SWAT model. "file:OUTPUT.RCH" #The associated river channel output file OUTPUT.RCH is the core data source for watershed outlet hydrological data. ], "related_parameters": [ "param:OUTPUT.RCH:FLOW_OUT", # Associate the outflow parameter of OUTPUT.RCH to characterize water production. "param:OUTPUT.RCH:TOTNkg", #The total nitrogen output parameter associated with OUTPUT.RCH characterizes nitrogen production. "param:OUTPUT.RCH:TOTPkg" #Related to the total phosphorus output parameter of OUTPUT.RCH, characterizing phosphorus production. ] }, { "step_id": 2, "title": "Extracting annual data from 2012-2015", "description": "Extract annual data for four years, from 2012 to 2015, from the OUTPUT.RCH file. Ensure the time step is set to annual output, or summarize the annual totals from monthly / daily data. Focus on data from the outlet section of the Heidingzi watershed." "related_files": [ "file:OUTPUT.RCH" ], "related_parameters": [ "param:OUTPUT.RCH:FLOW_OUT", "param:OUTPUT.RCH:TOTNkg", "param:OUTPUT.RCH:TOTPkg" ] }, { "step_id": 3, "title": "Calculate and compare output for each year", "description": "The extracted annual data are organized and compared. The total outflow, total nitrogen output, and total phosphorus output are calculated for each year, and annual comparison tables or charts are created to visually display the changing trends of each indicator from 2012 to 2015." "related_files": [ "file:OUTPUT.RCH" ], "related_parameters": [ "param:OUTPUT.RCH:FLOW_OUT", "param:OUTPUT.RCH:TOTNkg", "param:OUTPUT.RCH:TOTPkg" ] }, { "step_id": 4, "title": "Identifying the year with the highest output", "description": "Based on the comparative analysis results, the years with the highest output of water, total nitrogen, and total phosphorus were identified. The maximum values ​​for these three indicators may occur in different years, which needs to be explained separately. Possible reasons, such as changes in rainfall and land use, are analyzed." "related_files": [ "file:OUTPUT.RCH" ], "related_parameters": [ "param:OUTPUT.RCH:FLOW_OUT", "param:OUTPUT.RCH:TOTNkg", "param:OUTPUT.RCH:TOTPkg" ] }, { "step_id": 5, "title": "Auxiliary Analysis of Watershed Internal Output Characteristics", "description": "The output characteristics of each sub-basin were analyzed using the OUTPUT.SUB file to understand the spatial distribution of water yield and nutrient production within the basin. Parameters such as WYLD, ORGN, SOLP, and SEDP were used to verify the validity of the basin outlet data and identify the main contributing areas." "related_files":[ "file:OUTPUT.SUB" ], "related_parameters": [ # Associate core parameters of OUTPUT.SUB to adapt to sub-basin spatial analysis needs "param:OUTPUT.SUB:WYLD", #Correlate sub-basin water yield parameters to verify the rationality of the outlet water yield. "param:OUTPUT.SUB:ORGN", #Analyze the spatial distribution of nitrogen by correlating organic nitrogen output parameters in sub-basins. "param:OUTPUT.SUB:SOLP", #Analyze the spatial distribution of phosphorus by correlating soluble phosphorus output parameters in sub-basins. "param:OUTPUT.SUB:SEDP" #Correlate sub-basin particulate phosphorus output parameters to supplement the spatial analysis dimensions of phosphorus. ] } ] By explicitly referencing the retrieved entity ID (such as file:OUTPUT.RCH, param:OUTPUT.RCH:FLOW_OUT, etc.), the natural language requirements are thus grounded in specific SWAT files and variables.

[0163] The SWAT watershed hydrological model task planning system provided in this embodiment realizes intelligent operation of the entire process from user natural language requirements to SWAT watershed hydrological model executable task planning. It can accurately match the SWAT file / parameter structure, improve the professionalism, accuracy and executability of task planning, and solve the problems of high operation threshold, large amount of manual workload and unstable and unexecutable output of general large model in traditional SWAT watershed hydrological models.

[0164] According to an embodiment of the present invention, a SWAT watershed hydrological model task planning method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0165] This embodiment provides a SWAT watershed hydrological model task planning method, which can be used in the aforementioned SWAT watershed hydrological model task planning system 1. Figure 7 This is a flowchart of the SWAT watershed hydrological model task planning method according to an embodiment of the present invention, such as... Figure 7 As shown, the process includes the following steps: Step S701: Obtain the domain knowledge source of the SWAT watershed hydrological model, and construct a knowledge graph file based on the domain knowledge source.

[0166] For the specific process, please refer to the above description of the functions of the knowledge graph construction module 3 in the SWAT watershed hydrological model task planning system 1, which will not be repeated here.

[0167] Step S702: Based on the knowledge graph file, generate a file-level compressed index file and a parameter-level compressed index file.

[0168] For the specific process, please refer to the above description of the function of the embedded index building module 4 in the SWAT watershed hydrological model task planning system 1, which will not be repeated here.

[0169] Step S703: When the natural language task description sent by the user terminal is received, the natural language task description is processed based on the file-level compressed index file and the parameter-level compressed index file, and a target mapping structure is established.

[0170] The target mapping structure is used to reflect the correspondence between File entity IDs and Parameter entity IDs in the SWAT watershed hydrological model.

[0171] The specific process can be found in the above description of the query coding and two-stage retrieval module 5 in the SWAT watershed hydrological model task planning system 1, and will not be repeated here.

[0172] Step S704: Based on the target mapping structure and knowledge graph file, generate the target entity JSON text.

[0173] For the specific process, please refer to the above description of the function of the context building module 6 in the SWAT watershed hydrological model task planning system 1, which will not be repeated here.

[0174] Step S705: Obtain the target large language model, and input the target entity JSON text and natural language task description into the target large language model to obtain the SWAT watershed hydrological model task planning JSON.

[0175] For the specific process, please refer to the above description of the function of the large language model task planning module 7 in the SWAT watershed hydrological model task planning system 1, which will not be repeated here.

[0176] Step S706: Send the task planning JSON to the user terminal.

[0177] For the specific process, please refer to the above description of the function of the large language model task planning module 7 in the SWAT watershed hydrological model task planning system 1, which will not be repeated here.

[0178] The SWAT watershed hydrological model task planning method provided in this embodiment realizes the entire process from SWAT domain knowledge modeling to user-end acquisition of structured task planning JSON. It solves the problems of large workload, high threshold, and error-proneness in traditional SWAT watershed hydrological model configuration and analysis, as well as the inability of general large models to reliably generate SWAT task planning chains. It improves the intelligence, accuracy, and executability of SWAT watershed hydrological model task planning, and realizes efficient planning and operation of SWAT watershed hydrological models under natural language interaction.

[0179] In one example, a task planning system and method for SWAT watershed hydrological models based on domain knowledge graph enhancement is provided, such as... Figure 8 As shown, it includes: a knowledge graph construction module; an embedded index construction module; a query encoding and two-stage retrieval module; a context construction module; and a large language model task planning module.

[0180] The main relationships between the modules are as follows: the knowledge graph construction module parses SWAT-related configurations, output instructions, and other information into a unified knowledge graph file for use by the embedding index construction module and the query encoding and retrieval module; the embedding index construction module generates and stores file-level and parameter-level embedding indexes based on knowledge graph entities; the query encoding and two-stage retrieval module receives the user's natural language task description and embedding index, and outputs the related File and Parameter entity sets; the context construction module combines the retrieval results with the original knowledge graph entity information into an LLM-consumable JSON context; and the large language model task planning module generates structured task planning JSON based on the user's question and context.

[0181] Specifically as follows: 1. Knowledge graph construction module.

[0182] The knowledge graph construction module extracts entities and relationships from data sources such as the input / output manuals, configuration file templates, and sample projects of the SWAT model, including but not limited to: File entity: Represents SWAT input, output and intermediate files, such as meteorological input files, land use input files, river output files, etc. Each File entity contains attributes such as file name, description, spatial / temporal scale, and data format; Parameter entity: Represents the variable or parameter field in each file, such as the outflow of the river section, total nitrogen concentration, management measures parameters, etc. Each Parameter entity contains attributes such as variable name, unit, physical meaning, column or position; Relational entities include FILE_HAS_PARAMETER (file-parameter membership relationship), which are used to indicate the file to which the parameter belongs.

[0183] The entities and relationships mentioned above can be organized into a JSON-formatted knowledge graph file, where the graph.entities field stores all entities and the graph.relationships field stores all relationships.

[0184] 2. Embedded index building module.

[0185] The embedded index building module includes: an entity text generation submodule and an embedded computation and storage submodule.

[0186] Entity text generation submodule: For each File or Parameter entity, its complete JSON structure (including id, type, attributes, etc.) is serialized into text and used as input to the embedded model to ensure that important information such as units and descriptive text is not lost.

[0187] Serialization processing: The File / Parameter entities in the knowledge graph are not pruned or rewritten. Instead, their original entity objects (including all fields such as id, type, and attributes) are directly serialized into text using JSON as model input, generating a stable JSON string without escaping Chinese characters for each entity.

[0188] The embedding computation and storage submodule employs sentence vector models such as Qwen3-Embedding-0.6B to vectorize the aforementioned entity text, obtaining vector representations of dimension D. Vectors from all File entities are combined to form a file embedding matrix, and vectors from all Parameter entities are combined to form a parameter embedding matrix. A mapping relationship is established between entity IDs and vector row indices. Finally, the entity ID array and embedding matrix are saved as compressed index files, for example, as matrix files or compressed arrays in the embedding index directory.

[0189] This module can run offline, and the embedded index is usually recalculated and saved only when the knowledge graph undergoes a major update, thereby avoiding repeated calculations during the online query stage and improving response speed.

[0190] Among them, Qwen3-Embedding-0.6B belongs to the existing pre-trained text embedding (sentence vector) model, indicating that the embedding model is a replaceable existing module: as long as the entity text and user query can be mapped to the same vector space and similarity calculation can be performed, it can be used in the retrieval and task planning process of this application.

[0191] Furthermore, the basic principle of its vectorization (generating sentence vectors) is as follows: First, the input entity JSON text is tokenized and converted into a token sequence; then, the context representation (hidden states) of each token is obtained through a Transformer encoder (multi-layer self-attention network); subsequently, pooling is used to aggregate the variable-length token representations into a fixed-length vector. The SentenceTransformer version configuration used in this application employs "last-token pooling," which extracts the vector from the last valid position corresponding to the attention_mask in the last_hidden_state as the sentence vector output, with a default dimension of 1024. Finally, L2 normalization is applied to the vectors to make them fall on a unit sphere, facilitating the calculation of cosine similarity using dot product, thus achieving a retrieval ranking where the more semantically relevant the data, the higher the similarity.

[0192] Furthermore, the vector row index refers to the row number of the vector corresponding to each entity in the file embedding matrix / parameter embedding matrix. Furthermore, each row of the file embedding matrix corresponds to a File entity vector; each row of the parameter embedding matrix corresponds to a Parameter entity vector.

[0193] Furthermore, establishing a mapping relationship between entity IDs and vector row indices refers to creating a correspondence table between ID and row number, which is used to quickly locate the specific row position of an entity in the matrix.

[0194] Furthermore, the specific implementation of saving the entity ID array and the embedding matrix as compressed index files involves saving them as two separate compressed index files: file_embeddings.npz: Contains an array of ids and an embeddings matrix for the File. parameter_embeddings.npz: Contains the ids array and embeddings matrix of the parameters. Furthermore, there is no need to store the "mapping relationship" (id->row number) separately. This is because the row number mapping can be directly reconstructed from the ids array during loading, and is considered redundant information.

[0195] Furthermore, the specific process is as follows: 1. Extract the File entity list and Parameter entity list from the knowledge graph respectively, and fix their order (the order of the list is the row order of the subsequent matrix). 2. Generate serialized text (complete JSON text) for each entity, encode it into a vector using an embedding model; stack all vectors into a matrix embeddings (shape [N,D]) in the order of the entity list, and generate ids (length N) in the same order. 3. Save them separately using compressed array format: Write two keys, ids and embeddings, into each .npz file; 4. When using it, load the .npz file to retrieve ids and embeddings, and then reconstruct the mapping relationship between "entity id and vector row index" by traversing each line of the .npz file id_to_row={id_:ifori,id_inenumerate(ids)}, which is used to quickly locate the corresponding row vector in the matrix by id.

[0196] 3. Query coding and two-stage retrieval module.

[0197] After receiving the natural language task description initiated by the user, the query encoding and two-stage retrieval module performs the following steps: Step S1: Using the same Qwen3-Embedding-0.6B model as the entity embedding, encode the user's natural language question into a query vector q, with the same dimension as the entity vector; to improve the efficiency of subsequent similarity calculation, L2 regularization can be applied to the vector during encoding.

[0198] Step S2 (File-level Retrieval): Calculate the similarity between the query vector and each file vector (i.e., the embedding vector corresponding to each File entity in the knowledge graph) in the file embedding matrix. In this implementation, assuming the vectors have been normalized, the dot product is used as an equivalent form of cosine similarity. The top K_f file entity IDs are selected based on similarity from high to low to form a candidate file set, where K_f is a preset integer parameter, for example, 3 to 10.

[0199] Step S3 (Parameter Layer Retrieval): For each selected file entity f, based on the FILE_HAS_PARAMETER relationship in the knowledge graph, extract the parameter subset belonging to that file from the Parameter entity; calculate the similarity with the query vector q only on the parameter embedding submatrix corresponding to the subset, select the top K_p parameter IDs (K_p is a preset integer, such as 5~20), and generate a mapping structure with file ID as the key and the parameter ID list as the value.

[0200] Furthermore, the two-stage SWAT model knowledge graph retrieval process is as follows: Figure 9 As shown.

[0201] Furthermore, through the above two-stage retrieval, the parameter retrieval stage is constrained by the file layer relationship, avoiding interference from parameters unrelated to the current file, and improving the matching degree between the retrieval results and the SWAT file structure.

[0202] Furthermore, the implementation method of the two-stage retrieval can be adjusted, for example: After file-level retrieval, parameters within the same file are first pre-filtered based on rules (e.g., only output variables are retained), and then sorted by vector similarity. Introduce threshold filtering into the parameter-level search results to retain only parameters with a similarity greater than a certain set value; A third stage of retrieval is added, which further reorders the selected parameters based on relational paths or graph convolutional networks.

[0203] 4. Context building module.

[0204] The context building module selects the corresponding original entity JSON from the knowledge graph entity list (i.e., all entities in the knowledge graph file obtained from the knowledge graph building module) based on the file ID and parameter ID contained in the search results. It then lists and serializes the selected entities into JSON text, maintaining the integrity of the original fields.

[0205] The JSON text output by this module serves as the knowledge context of the large language model. Its content includes the id, type, and various attribute fields in attributes (such as description, unit, spatiotemporal granularity, and file to which it belongs) of each entity, enabling the large language model to fully perceive SWAT semantic information when generating task plans.

[0206] 5. Large Language Model Task Planning Module.

[0207] The large language model task planning module includes a prompt generation submodule and a task planning generation submodule.

[0208] Hint Generation Submodule: Based on predefined hints, the module assigns roles to the large language model, clarifies its task as "task planning assistant based on SWAT model knowledge graph", explains the type and meaning of the input entities and provides the target structure and field explanation of the task planning JSON.

[0209] The task planning and generation submodule takes the user's natural language question and the entity JSON generated by the context building module as the user's message input to the large language model, requiring the model to output only a single JSON object conforming to a predefined structure. For example, the output JSON should contain at least the following fields: user_intent: summarizes the user's core needs; assumptions: List the assumptions made by the model when there is ambiguity in the requirements; files: Lists file entities related to the task, including fields such as id, name, role, and source. The id corresponds to the File entity ID in the knowledge graph, and the source indicates whether it comes from the graph or model inference. parameters: Lists the parameter entities related to the task, including fields such as id, name, file_id, role, and source; `plan_steps`: A list of task steps, each containing fields such as `step_id`, `title`, `description`, `related_files`, and `related_parameters`, explicitly binding abstract steps to specific files and parameter IDs. An example of the final model output is shown below. Figure 10 As shown.

[0210] Furthermore, during the task planning and generation process, the large language model combines the user's question and entity context to understand the purpose of the SWAT file and parameters, and maps them to several operation steps, such as determining the output file to be viewed, confirming the relevant parameter columns, setting the simulation time range, exporting and analyzing the result data, etc.

[0211] The SWAT watershed hydrological model task planning system and method based on domain knowledge graph enhancement provided in this example have the following effects: 1. Achieve precise task mapping at the SWAT file / parameter level.

[0212] By modeling SWAT files and parameters as File and Parameter entities in a knowledge graph and referencing the entity IDs throughout the retrieval and generation phases, the task planning results in this example can accurately locate specific files and parameter fields. This allows users or downstream tools to directly access files, read parameters, and perform configuration operations based on the output JSON, solving the problem that existing technologies can only provide conceptual suggestions and cannot be directly implemented.

[0213] 2. Improve retrieval accuracy while preserving graph structure semantics.

[0214] This example employs a two-stage retrieval strategy: first, it coarsely filters files in the File entity space, and then it performs a fine-grained retrieval in the corresponding parameter subspace under the FILE_HAS_PARAMETER constraint, effectively reducing retrieval noise at the parameter level. Simultaneously, by using the complete JSON text of the entity when constructing the entity embedding, the vector representation can carry multi-dimensional semantic information such as units and spatiotemporal scales, further enhancing the professionalism and consistency of the retrieval results.

[0215] 3. Output structured task planning results that can be executed automatically.

[0216] This example constrains the output format of a large language model, forcing the generation of task planning JSON with fixed fields. This results in a stable structure and clear field meanings, making it easy to parse and utilize by scripts or graphical interfaces. As a result, functions such as automatic configuration of SWAT projects, batch generation of simulation tasks, and automatic export and analysis of results can be achieved, significantly enhancing the degree of automation and scalability.

[0217] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0218] The following is a detailed reference. Figure 11The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from memory 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0219] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 11 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0220] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a memory 508, or installed from a ROM 502. When the computer program is executed by the processor 501, it performs the functions defined in the SWAT watershed hydrological model task planning method of the present invention.

[0221] Figure 11 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0222] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the SWAT watershed hydrological model task planning method shown in the above embodiments is implemented.

[0223] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0224] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A SWAT watershed hydrological model task planning system, characterized in that, The system is connected to the user terminal; the system includes: a knowledge graph construction module, an embedded index construction module, a query encoding and two-stage retrieval module, a context construction module, and a large language model task planning module; The knowledge graph construction module is connected to the embedded index construction module, the query encoding and two-stage retrieval module, and the context construction module, respectively; the embedded index construction module and the query encoding are connected to the two-stage retrieval module; the context module is connected to the query encoding and two-stage retrieval module and the large language model task planning module, respectively. The knowledge graph construction module is used to obtain the domain knowledge source of the SWAT watershed hydrological model and construct a knowledge graph file based on the domain knowledge source. The embedded index building module is used to generate file-level compressed index files and parameter-level compressed index files based on the knowledge graph file; The query encoding and two-stage retrieval module is used to process the natural language task description sent by the user terminal upon receiving the natural language task description, based on the file-level compressed index file and the parameter-level compressed index file, and to establish a target mapping structure. The target mapping structure is used to reflect the correspondence between the File entity ID and the Parameter entity ID of the SWAT watershed hydrological model. The context building module is used to generate target entity JSON text based on the target mapping structure and the knowledge graph file; The large language model task planning module is used to obtain the target large language model, input the target entity JSON text and the natural language task description into the target large language model, obtain the task planning JSON of the SWAT watershed hydrological model, and send the task planning JSON to the user terminal.

2. The system according to claim 1, characterized in that, The knowledge graph construction module includes: an acquisition submodule, an extraction submodule, and a construction submodule, wherein the extraction submodule is connected to the acquisition submodule and the construction submodule, respectively. The acquisition submodule is used to acquire the domain knowledge source of the SWAT watershed hydrological model; The extraction submodule is used to extract the domain knowledge source to obtain multiple File entities, multiple Parameter entities, and multiple entity relationships; The construction submodule is used to construct the knowledge graph file based on the multiple File entities, the multiple Parameter entities, and the multiple entity relationships.

3. The system according to claim 2, characterized in that, The embedded index construction module includes: an entity text generation submodule and an embedded calculation and storage submodule, wherein the entity text generation submodule and the embedded calculation and storage submodule are connected. The entity text generation submodule is used to serialize the JSON structure of the multiple File entities and the JSON structure of the multiple Parameter entities in the knowledge graph file to obtain the JSON text of the multiple File entities and the JSON text of the multiple Parameter entities. The embedded computing and storage submodule is used to generate the file-level compressed index file and the parameter-level compressed index file based on the JSON text of the multiple File entities and the JSON text of the multiple Parameter entities.

4. The system according to claim 3, characterized in that, The embedded computing and storage submodule includes: a vectorization unit, an establishment unit, a generation unit, and an encapsulation unit. The establishment unit is connected to the vectorization unit, the generation unit, and the encapsulation unit, respectively. The generation unit and the encapsulation unit are connected. The vectorization unit is used to use a preset equal sentence vector model to vectorize the JSON text of the multiple File entities and the JSON text of the multiple Parameter entities respectively, so as to obtain multiple File entity vectors and multiple Parameter entity vectors. The establishment unit is used to establish a file embedding matrix based on the plurality of File entity vectors, and to establish a parameter embedding matrix based on the plurality of Parameter entity vectors; The generation unit is configured to generate a File entity ID array based on the file embedding matrix, and to generate a Parameter entity ID array based on the parameter embedding matrix. The encapsulation unit is used to encapsulate the File entity ID array and the file embedding matrix to obtain the file-level compressed index file, and to encapsulate the Parameter entity ID array and the parameter embedding matrix to obtain the parameter-level compressed index file.

5. The system according to claim 4, characterized in that, The embedded computing and storage submodule is also used to regenerate a new file-level compressed index file and a new parameter-level compressed index file based on the knowledge graph file when the knowledge graph file is updated to meet preset requirements.

6. The system according to claim 4, characterized in that, The query encoding and two-stage retrieval module includes: a loading submodule, an encoding submodule, a first calculation and determination submodule, a first determination submodule, a second calculation and determination submodule, and an establishment submodule; The loading submodule is connected to the encoding submodule, the first calculation and determination submodule, the first determination submodule, and the second calculation and determination submodule, respectively; the encoding submodule is connected to the first calculation and determination submodule and the second calculation and determination submodule, respectively; the first determination submodule is connected to the first calculation and determination submodule and the second calculation and determination submodule, respectively; the establishment submodule is connected to the first calculation and determination submodule and the second calculation and determination submodule, respectively. The loading submodule is used to load the file-level compressed index file and the parameter-level compressed index file when it receives the natural language task description sent by the user terminal, and to determine the File entity ID array, the file embedding matrix, the Parameter entity ID array and the parameter embedding matrix; The encoding submodule is used to encode the natural language task description using the preset equal sentence vector model to obtain a query vector; The first calculation and determination submodule is used to calculate multiple first similarity values ​​between the query vector and each File entity vector in the file embedding matrix, and determine multiple target File entity IDs in the File entity ID array based on the multiple first similarity values; The first determining submodule is used to determine a subset of Parameter entities corresponding to the multiple target File entity IDs based on the multiple entity relationships in the knowledge graph file, and to determine a parameter embedding submatrix in the parameter embedding matrix based on the subset of Parameter entities; The second calculation and determination submodule is used to calculate multiple second similarity values ​​between the query vector and each Parameter entity vector in the parameter embedding submatrix, and to determine multiple target Parameter entity IDs in the Parameter entity ID array based on the multiple second similarity values; The establishment submodule is used to establish the target mapping structure based on the multiple target File entity IDs and the multiple target Parameter entity IDs.

7. The system according to claim 1, characterized in that, The context construction module includes: a second determining submodule and a processing submodule, wherein the second determining submodule and the processing submodule are connected; The second determining submodule is used to determine multiple original File entities and multiple original Parameter entities in the knowledge graph file based on the target mapping structure; The processing submodule is used to serialize the JSON structures of the multiple original File entities and the multiple original Parameter entities respectively, and determine the JSON text of the target entity.

8. The system according to claim 1, characterized in that, The large language model task planning module includes: a prompt generation submodule and a task planning generation submodule, wherein the prompt generation submodule and the task planning generation submodule are connected. The prompt generation submodule is used to configure prompt constraints on a preset large language model using a preset prompt template to obtain the target large language model; The task planning generation submodule is used to input the natural language task description and the target entity JSON text into the target large language model, generate the task planning JSON of the SWAT watershed hydrological model that conforms to the predefined structure, and output the task planning JSON to the user terminal.

9. A SWAT watershed hydrological model task planning method, characterized in that, The method is used in the SWAT watershed hydrological model task planning system according to any one of claims 1 to 8; the method includes: Obtain the domain knowledge source of the SWAT watershed hydrological model, and construct a knowledge graph file based on the domain knowledge source; Based on the knowledge graph file, generate a file-level compressed index file and a parameter-level compressed index file; When a natural language task description is received from the user, the natural language task description is processed based on the file-level compressed index file and the parameter-level compressed index file, and a target mapping structure is established. The target mapping structure is used to reflect the correspondence between the File entity ID and the Parameter entity ID of the SWAT watershed hydrological model. Based on the target mapping structure and the knowledge graph file, generate the target entity JSON text; Obtain the target large language model, and input the target entity JSON text and the natural language task description into the target large language model to obtain the task planning JSON of the SWAT watershed hydrological model; The task planning JSON is sent to the user's client.

10. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the SWAT watershed hydrological model task planning method of claim 9.

Images