A network routing meta-operator splitting and intent matching method and system based on a large language model
Patent Information
- Application Number
- CN202610647234.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-12
- Publication Date
- 2026-09-25
AI Technical Summary
[0010]发明目的:本发明的目的是提供一种基于大语言模型的网络路由元算子拆分与意图匹配方法及系统,解决不同场景下策略复用性差,策略计算或生成结果在动态变化环境下波动大、可解释性差的问题,通过将路由意图拆分为可计算、可组合的网络路由元算子,包括但不限于状态元算子、目标元算子、约束元算子、动作元算子和校验元算子,进而实现路由意图与元算子库之间的匹配与组合、生成结构化路由策略并映射为可执行网络配置的意图驱动路由
[0061]1、本发明通过构建路由元算子语义体系,将自然语言路由意图拆分为目标元算子与约束元算子,并装配形成元算子图,实现意图与网络能力的统一语义映射,提升意图落地准确性;
Smart Images

Figure CN122824646A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of artificial intelligence and network automation management technology, and in particular to a method and system for network routing meta-operator decomposition and intent matching based on a large language model. Background Technology
[0002] In scenarios such as industrial IoT, medical private networks, and data center networks, services have clear and stringent requirements for network transmission quality. Common requirements include low latency for critical business links, bandwidth assurance for high-traffic services, and low packet loss rate control under sudden congestion and link fluctuation scenarios. At the same time, these networks typically exhibit diverse topologies, complex service types, significant traffic fluctuations, and frequent dynamic changes in link status, making the generation, adjustment, and verification of routing strategies highly complex in engineering terms.
[0003] Existing network routing and traffic engineering technologies typically rely on routing protocol metrics and human experience for parameter tuning, or on centralized controllers, such as SDN controllers and network orchestration systems, to collect network status, calculate paths, and then distribute configurations. Under the intent-driven networking concept, there are also solutions that convert the goals and constraints of operations personnel into policies through predefined intent models and then execute them. While these methods improve automation to some extent, they still struggle to balance availability, controllability, and verifiability when facing multi-objective constraints, cross-scenario migration, and dynamic network states.
[0004] In recent years, large language models, due to their strong natural language understanding and reasoning capabilities, have been attempted to transform user natural language intents into operational tasks or policy suggestions, thereby lowering the barrier to policy generation. However, for routing policy generation tasks driven by natural language intents plus form / log / network status data, without a unified intermediate semantic abstraction and engineering constraint mechanism, it remains difficult to stably generate executable and verifiable routing policies. Therefore, existing technologies still have the following problems:
[0005] 1) The mapping from intent to routing policy lacks composable intermediate semantic units. Existing solutions often directly map intent to configuration templates or rule sets, making it difficult to decompose the objects, goals, constraints, priorities, and scope of application contained in the intent into the smallest computable and reusable units. This results in poor policy reusability in different scenarios, and the fine-grained constraints expressed by intent, such as simultaneously constraining latency, bandwidth, and packet loss rate, are difficult to implement stably.
[0006] 2) The difficulty in forming a unified semantic representation of multi-source network state data leads to unstable policy generation. The network state on which routing decisions depend typically comes from heterogeneous data sources such as forms, logs, telemetry, alarms, and configuration libraries. The granularity and semantic scope of fields are inconsistent, the update frequency varies, and missing data and noise are common. Existing technologies mostly rely on manual cleaning or fixed rule fusion, which makes it difficult to form a state expression consistent with the intent constraints. As a result, the policy calculation or generation results fluctuate greatly in dynamic environments and have poor interpretability.
[0007] 3) Intent-driven solutions based on predefined models have high expansion costs and insufficient generalization capabilities. Existing intent-driven / policy-driven systems typically require predefined intent templates and mapping rules. When new services, new combinations of constraints, or new network capabilities emerge, experts need to redesign the field, rule, and policy mapping logic, resulting in long iteration cycles, high maintenance costs, and extensive re-adaptation when migrating across network scenarios.
[0008] 4) Directly using large language models to generate routing policies carries risks of uncontrollability and unverifiability. If natural language intent and network status are directly input into a large language model and a routing policy or configuration is required to be output, the model output may exhibit randomness and inconsistency. Moreover, the output is mostly unstructured description, making it difficult to directly map into executable commands for devices. At the same time, the lack of consistency verification, conflict detection, and rollback mechanisms for constraints such as latency, bandwidth, and packet loss rate before and after generation can easily lead to configuration risks and service interruption risks.
[0009] 5) Lack of routing-oriented intent matching and capability assembly mechanisms. Existing technologies often fail to establish searchable and matchable routing capability knowledge units, making it impossible to accurately match and combine the goals and constraints in the intent with the available capabilities on the network side. Consequently, it is difficult to form a traceable link between intent, capability, policy, and command, making it difficult to implement closed-loop optimization of generation, verification, execution, and feedback in engineering. Summary of the Invention
[0010] Purpose of the Invention: The purpose of this invention is to provide a method and system for network routing meta-operator decomposition and intent matching based on a large language model, which solves the problems of poor policy reusability in different scenarios, large fluctuations in policy calculation or generation results in dynamic environments, and poor interpretability. By decomposing routing intents into computable and composable network routing meta-operators, including but not limited to state meta-operators, target meta-operators, constraint meta-operators, action meta-operators, and verification meta-operators, the invention achieves matching and combination between routing intents and the meta-operator library, generates structured routing policies, and maps them to intent-driven routes with executable network configurations.
[0011] Technical Solution: A network routing meta-operator decomposition and intent matching method based on a large language model, which abstracts the target network into a graph. The set of network nodes Used to represent network devices and link sets. Used to represent directed links between nodes; for any candidate path The path metrics are defined to include at least latency. Available bandwidth Packet loss rate The routing intent is broken down into computable and composable network routing meta-operators, including state meta-operators, target meta-operators, constraint meta-operators, action meta-operators, and verification meta-operators. Each meta-operator... It features standardized input / output, semantic description, applicable scenario labels, parameter range, pre- and post-dependencies, and executable mapping rules; thereby achieving the matching and combination between routing intents and the meta-operator library, generating structured routing strategies, and mapping them to intent-driven routes with executable network configurations; the steps include the following:
[0012] S1: Obtain the user's natural language routing intent and network status data; preprocess and fuse the network status data to form a unified status view. ;
[0013] S2 leverages the instruction-following capabilities and domain-specific constraints of a large language model to parse natural language routing intents and generate structured intent objects. ;
[0014] S3, unify state view Abstracted as a set of state meta-operators ;
[0015] S4, Building a routing meta-operator library And define a standardized data structure for each meta-operator;
[0016] S5 will structure the intent object Split into a set of target meta-operators With the set of constraint meta-operators and with the routing meta-operator library Perform matching, generate a candidate set of meta-operators, and assemble them into a meta-operator graph. ;
[0017] S6, based on the metaoperator graph Construct a controlled prompt template and inject structured intent fields, state meta-operator summaries, a list of allowed meta-operators, field constraints of the policy DSL, and security constraints to form a standardized controlled prompt. ;
[0018] S7 will be controlled. Input a large language model to generate a structured routing strategy. ;
[0019] S8, for structured routing policies Perform verification and risk control;
[0020] When verification fails or conflict detection triggers a risk threshold, a structured failure reason and correction suggestions are generated and fed back to step S6 to rebuild the prompt before generating the structured routing policy. Until the verification passes or the rollback strategy is triggered;
[0021] If the verification passes, proceed to step S9;
[0022] S9 will pass the verification of the structured routing policy. Mapped to control commands / configurations that can be executed by network devices or controllers, and then issued and executed through the interface;
[0023] S10 continuously monitors latency, bandwidth, and packet loss rate after execution to form samples of intent, strategy, and effect; if the monitoring data deviates, it updates the applicability weights, parameter ranges, or prompts the template selection strategy in the meta-operator library.
[0024] Furthermore, the network status data includes at least one or more of the following: form data, log data, telemetry monitoring data, topology and link attribute data, and device capability and current network policy data.
[0025] Furthermore, the structured intent object It should include at least: business object / scope field, multi-objective field, constraint field, scenario label field, confidence and disambiguation field.
[0026] Furthermore, the set of state element operators It includes at least: topology status meta-operators, link metric meta-operators, congestion queue meta-operators, fault alarm meta-operators, and device capability meta-operators, and adds a timestamp and credibility tag to each status meta-operator.
[0027] Furthermore, the standardized data structure includes at least: meta-operator identifier, type, semantic description, input parameter definition, output field definition, applicable scenario label, parameter range, prerequisite dependencies, executable mapping rules, and risk level marker.
[0028] Furthermore, the meta-operator matching and assembly includes the following steps:
[0029] S51, perform initial screening based on scene labels and meta-operator types to obtain a candidate set. ;
[0030] S52, Encode the intent field description into a vector representation. The semantic description of the meta-operator is encoded as a vector representation. Calculate semantic similarity and sort them from highest to lowest similarity; the calculation is as follows:
[0031] ,
[0032] in, Represents the routing meta-operator library The k-th candidate meta-operator in; Represents a structured intent object With candidate meta-operators The semantic similarity is used to measure the degree of matching between the current intent and the candidate meta-operator;
[0033] S53, perform precondition checks on candidate meta-operators and generate dependency consistency scores. Prerequisites include whether the required state meta-operator exists, whether the parameter range is available, and whether it conflicts with the existing network capabilities.
[0034] S54. Based on semantic similarity and dependency consistency scores, calculate the matching score and select the Top-K meta-operator with the highest score:
[0035] ,
[0036] in, , These are weighting coefficients, configured according to the scenario. For matching scores;
[0037] Step 55: Based on the meta-operator dependencies, assemble the action meta-operators into a meta-operator graph in the order of candidate path generation, constraint filtering, multi-objective scoring, policy compilation, verification rollback, and executable mapping. or meta-operator sequence It also generates parameter suggestions and strategy skeletons.
[0038] Furthermore, regarding structured routing strategies The verification includes at least: structural legality verification, constraint consistency verification, executability verification, and conflict detection;
[0039] For candidate paths The hard constraint verification is expressed as:
[0040] ,
[0041] in, This represents the corresponding time delay constraint threshold in the structured intent. This represents the available bandwidth constraint threshold corresponding to the structured intent. This represents the packet loss rate constraint threshold corresponding to the structured intent. Indicates time delay. Indicates available bandwidth. Indicates packet loss rate;
[0042] The candidate path set satisfying the hard constraints is then ranked according to multiple objectives; the comprehensive cost is calculated after normalizing the indicators. :
[0043] ,
[0044] in, , , Derived from intent weights or scenario default weights; , , These represent the results after normalizing latency, packet loss rate, and available bandwidth, respectively.
[0045] Further, controlled prompts The following conditions must be met:
[0046] The output must be in policy DSL format;
[0047] Only action meta-operators and fields declared in the meta-operator library are allowed to be referenced;
[0048] The critical threshold constraints must not be relaxed;
[0049] For uncertainties, a confidence level or alternative solutions must be output.
[0050] A network routing meta-operator decomposition and intent matching system based on a large language model is used to execute any of the methods described above. It is deployed in multi-scenario networks, with an intent-driven routing engine at its core, and works collaboratively with controllers / orchestrators, edge execution agents, and network devices / data planes. The intent-driven routing engine includes:
[0051] The input acquisition and status fusion module is used to receive users' natural language routing intentions and network status data, and to complete field normalization, time alignment, anomaly handling and missing data completion to form a unified status view.
[0052] The intent parsing and structuring module is used to parse natural language intents into structured intents. ;
[0053] The routing meta-operator library module is used to store the routing meta-operator library and its dependencies, parameter ranges, and executable mapping rules;
[0054] Meta-operator matching and assembly module for use with structured intent With state element operator Complete meta-operator recall, semantic matching, dependency consistency verification and assembly, and output meta-operator graph. ;
[0055] Controlled hint building module, used to build upon meta-operator graphs Generate controlled hints with whitelists / schemas to limit the actions and fields that can be used by large language models;
[0056] The policy generation module is used for reasoning in large language models, outputting structured policies based on controlled cues. ;
[0057] The policy verification and conflict detection module is used to verify structured policies. Performs structural verification, constraint consistency verification, capability executability verification, and conflict detection with existing network policies; generates structured feedback upon failure.
[0058] The strategy mapping and distribution module is used to map structured strategies. Mapped to control commands / configurations and distributed to controllers / orchestrators or edge execution agents / network devices;
[0059] The operation monitoring and closed-loop update module is used to collect latency, bandwidth, packet loss rate and logs / alarms / telemetry data, form intent, strategy and effect samples, and update the meta-operator library, prompt templates and weight parameters.
[0060] Compared with the prior art, the significant advantages of this invention are as follows:
[0061] 1. This invention constructs a semantic system of routing meta-operators, decomposes natural language routing intent into target meta-operators and constraint meta-operators, and assembles them into a meta-operator graph, thereby achieving a unified semantic mapping between intent and network capabilities and improving the accuracy of intent landing;
[0062] 2. This invention improves the stability and rationality of strategy generation by matching intent, meta-operators, and verifying dependency consistency, making multiple objective constraints such as latency, bandwidth, and packet loss rate combinable, filterable, and verifiable under a unified framework.
[0063] 3. This invention introduces a controlled prompting and structured strategy DSL output mechanism, which limits the generation of large language models within the semantic boundaries of meta-operators. The output results are parsable, verifiable, and mappable, enhancing the feasibility and controllability of the project.
[0064] 4. This invention reduces the risk of misconfiguration and policy conflict by implementing a structured feedback and feedback mechanism for failure reasons, thereby improving policy security and reliability.
[0065] 5. This invention constructs an operation monitoring and closed-loop update mechanism, which dynamically updates the meta-operator library, prompt templates, and weight parameters based on the execution effect, thereby improving the network's adaptability and long-term stability in dynamic environments. Attached Figure Description
[0066] Figure 1 This is a diagram illustrating the overall architecture of the network routing meta-operator splitting and intent matching system of the present invention.
[0067] Figure 2 This is a flowchart of the network routing meta-operator decomposition and intent matching method of the present invention;
[0068] Figure 3 This is a flowchart of the network routing meta-operator splitting, matching, and assembly process of the present invention;
[0069] Figure 4 This diagram illustrates the deployment and multi-scenario adaptation of the network routing meta-operator splitting and intent matching method of the present invention in industrial IoT, medical networks, and data center networks. Detailed Implementation
[0070] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Those skilled in the art should understand that the following embodiments are only used to explain the technical solutions and implementation paths of the present invention and do not constitute a limitation on the scope of protection; any equivalent substitutions or modifications made to the process sequence, module division, parameter settings, model selection, and interface implementation without departing from the concept of the present invention should fall within the scope of protection of the present invention.
[0071] This invention proposes a network routing meta-operator decomposition and intent matching method based on a large language model. This method is designed for scenarios such as industrial IoT, medical networks, and data center networks. Based on comprehensive consideration of multiple objective constraints such as latency, bandwidth, and packet loss rate, it performs unified semantic abstraction on user natural language routing intent and form / log / network status data, decomposing it into a set of computable, composable, and verifiable routing meta-operators. It then completes the matching and assembly of intent and meta-operator library, generates structured routing strategies with the participation of the large language model, and finally maps them into executable network configurations that support runtime feedback closed-loop optimization.
[0072] like Figure 1 As shown, a preferred system of the present invention adopts a four-layer decoupled architecture, including a requirement parsing layer, a routing capability layer, a large model layer, and a routing application layer. Each layer interacts through a structured intermediate representation, which includes at least a structured intent object. Set of state element operators Routing meta-operator library Meta-operator diagram Controlled prompts Structured Strategies (DSL) .
[0073] In the network scenario involved in this invention, the target network is abstracted as a graph. The set of network nodes Used to represent network devices such as routers, switches, and edge gateways; link sets Used to represent directed links between nodes. For any candidate path (Composed of a set of ordered links), its path metrics should include at least: latency Available bandwidth Packet loss rate The above indicators can be obtained by fusing network status data from multiple sources, such as telemetry, logs, forms, and monitoring systems.
[0074] Furthermore, this invention represents the user-input natural language routing intent as a structured intent object. It should include at least the following fields: business object / scope, target set, constraint set, priority / weight, scenario label, and confidence level. To achieve a traceable and verifiable link for intent capabilities, policies, and commands, this invention introduces routing meta-operators as unified intermediate semantic units and constructs a routing meta-operator library. Each meta-operator It features standardized input / output, semantic description, applicable scenario labels, parameter range, pre- and post-dependencies, and executable mapping rules.
[0075] Meta-operators include at least the following categories:
[0076] A1) State meta-operators: used to express the state of topology, link latency / bandwidth / packet loss, queue congestion, fault alarm, maintenance window, device capabilities, etc.
[0077] A2) Objective meta-operators: used to express objectives such as latency optimization, bandwidth guarantee, and packet loss suppression;
[0078] A3) Constraint meta-operators: used to express threshold constraints, path necessity / avoidance, intra-domain / cross-domain restrictions, isolation and security constraints, etc.
[0079] A4) Action meta-operators: used to express actions such as candidate path generation, constraint filtering, multi-objective scoring, path selection, policy compilation, and policy deployment;
[0080] A5) Verification meta-operators: used for expressing structure verification, constraint consistency verification, conflict detection, executability verification, simulation evaluation, rollback, etc.
[0081] To facilitate the engineering implementation of the large language model generation results, this invention defines a structured routing strategy as follows: Its fields include at least: business scope, target weight / priority, constraint set, candidate path or routing rules, action to be issued, rollback conditions, and explanation fields, so as to achieve parsing, verification, and mapping.
[0082] like Figure 2 As shown, the implementation process of the network routing meta-operator decomposition and intent matching method based on a large language model of the present invention includes the following steps:
[0083] Step 1: Obtain input and form a unified state view;
[0084] Obtain user natural language routing intent and multi-source network status data. The network status data includes at least one or more of the following: form data, log data, telemetry monitoring data, topology and link attribute data, device capability and live network policy data.
[0085] Furthermore, the network status data undergoes preprocessing and fusion, including field normalization, time alignment, outlier handling, and missing value completion, to form a unified status view. This is used for subsequent state element operator construction and constraint verification.
[0086] Step 2: Parse and structure the natural language routing intent;
[0087] By leveraging the instruction-following capabilities and domain-specific constraints of large language models, natural language routing intents are parsed to generate structured intent objects. A structured intent object must contain at least:
[0088] B1) Business object / scope fields: such as business flow identifier, service type, key terminal, tenant / slice, network segment, etc.;
[0089] B2) Multiple target fields: latency, bandwidth, packet loss rate, can coexist;
[0090] B3) Constraint fields: threshold, hard / soft constraint identifier, priority / weight, time window, etc.;
[0091] B4) Scene tag fields: Industrial IoT / Medical Network / Data Center, etc.;
[0092] B5) Confidence and Disambiguation Fields: Output candidate interpretations and confidence levels for fuzzy expressions.
[0093] Furthermore, the tones of "must," "priority," and "as much as possible" can be mapped to constraint strength parameters to distinguish between hard constraints and soft goals, thereby reducing ambiguity in the implementation of intentions.
[0094] Step 3, Unify the state view Abstracted as a set of state meta-operators ;
[0095] The set of state meta-operators includes at least: topology state meta-operators, link indicator meta-operators (latency / bandwidth / packet loss), congestion queue meta-operators, fault alarm meta-operators, and device capability meta-operators. Each state meta-operator is appended with a timestamp and a credibility marker for subsequent executability verification and risk control.
[0096] Step 4, Build the routing meta-operator library And define a standardized data structure for each meta-operator;
[0097] The standardized data structure of each meta-operator should include at least the following: meta-operator identifier, type, semantic description, input parameter definition, output field definition, applicable scenario label, parameter range, prerequisite dependencies, executable mapping rules, and risk level marker.
[0098] Meta-operators are classified into atomic meta-operators and combinatorial meta-operators according to their granularity:
[0099] Atomic operators are the smallest executable units, such as candidate path generation, threshold filtering, score sorting, strategy compilation, conflict detection, rollback, etc.
[0100] Combinatorial operators are templated processes assembled from multiple atomic operators according to their dependencies, used to improve cross-scenario reusability and deployment efficiency.
[0101] Step 5: Intent splitting, meta-operator matching, and meta-operator graph assembly;
[0102] Structured intent objects Split into a set of target meta-operators With the set of constraint meta-operators and with the routing meta-operator library Perform matching to generate a candidate set of meta-operators and the assembly result.
[0103] like Figure 3 As shown, the meta-operator matching and assembly of the present invention includes at least the following steps:
[0104] Step 51, Candidate Recall: Perform initial screening based on scene tags and meta-operator types to obtain a candidate set. .
[0105] Step 52, Semantic Matching and Ranking: Encode the intent field description into a vector representation. The semantic description of the meta-operator is encoded as a vector representation. Calculate semantic similarity and sort the results in descending order of similarity scores. Preferably, cosine similarity can be used.
[0106] (1)
[0107] in, Represents the routing meta-operator library The k-th candidate meta-operator in; Represents a structured intent object With candidate meta-operators The semantic similarity is used to measure the degree of matching between the current intent and the candidate meta-operator.
[0108] Step 53, Dependency Consistency Verification: Perform precondition checks on candidate meta-operators, such as whether the required state meta-operator exists, whether the parameter range is available, and whether it conflicts with the existing network capabilities, and further generate a dependency consistency score. .
[0109] Step 54, Matching Score Fusion and Selection: Combining the semantic similarity obtained in Step 52 and the dependency consistency score obtained in Step 53, calculate the matching score and select the Top-K meta-operator with the highest score:
[0110] (2)
[0111] in , These are weighting coefficients, which can be configured according to the scenario. For matching scores.
[0112] Step 55, Meta-operator graph assembly: Based on the meta-operator dependencies, assemble the action meta-operators into a meta-operator graph in the order of candidate path generation, constraint filtering, multi-objective scoring, policy compilation, verification rollback, and executable mapping. or meta-operator sequence It also generates parameter suggestions and strategy skeletons.
[0113] Step 6, based on the meta-operator graph Construct a controlled prompt template and inject structured intent fields, state meta-operator summaries, a list of allowed meta-operators, field constraints of the policy DSL, and security constraints to form a standardized controlled prompt. .
[0114] To improve generation stability and engineering controllability, controlled hints The following restrictions apply:
[0115] C1) The output must be in policy DSL format;
[0116] C2) Only action meta-operators and fields declared in the meta-operator library are allowed to be referenced;
[0117] C3) Critical threshold constraints must not be relaxed;
[0118] C4) For uncertain terms, the confidence level or alternative solutions must be output.
[0119] Step 7, Controlled prompts Input a Large Language Model (LLM) to generate a structured routing strategy. ;
[0120] Structured routing strategy It should include at least: business scope, target weight / priority, constraint set, candidate path or routing rules, action to be issued, rollback conditions and explanation fields.
[0121] Step 8, configure the structured routing policy. Perform verification and risk control;
[0122] The verification includes at least: structural legality verification, constraint consistency verification, executability verification and conflict detection; and optionally, simulation evaluation can be introduced for pre-deployment verification in high-risk scenarios.
[0123] For candidate paths The hard constraint verification can be expressed as:
[0124] (3)
[0125] in, This represents the corresponding time delay constraint threshold in the structured intent. This represents the available bandwidth constraint threshold corresponding to the structured intent. This represents the packet loss rate constraint threshold corresponding to the structured intent; the All of these originate from the structured intent constraint fields.
[0126] The candidate path set satisfying the hard constraints is ranked according to multiple objectives. Preferably, the comprehensive cost is calculated after normalizing the indicators. :
[0127] (4)
[0128] in, , , Derived from intent weights or scenario default weights; , , These represent the results after normalizing latency, packet loss rate, and available bandwidth, respectively.
[0129] When verification fails or conflict detection triggers a risk threshold, a structured failure reason and correction suggestion are generated, such as insufficient bandwidth, conflict with the existing network policy, unsupported device capabilities, or unmet constraints, and then fed back into the large language model to trigger regeneration.
[0130] like Figure 2As shown, if the verification in step 8 fails, structured feedback is output and fed back to step 6 to rebuild the controlled prompt template before generating the structured routing policy. If necessary, when the failure is due to a lack of dependency / capability, step 5 can be triggered, and then the closed-loop process of steps 6 to 8 can be entered until the verification is passed or the rollback strategy is triggered.
[0131] Step 9: Transfer the validated structured routing policy Mapped to control commands / configurations that can be executed by network devices or controllers, and then issued and executed through the interface;
[0132] Mapping can select appropriate actions for different network implementations, such as explicit path strategies, weight / metric adjustments, policy routing, queue and priority strategies, to achieve deployability across industrial, medical and data center scenarios.
[0133] Step 10: Continuously monitor the KPIs (such as latency, bandwidth, and packet loss rate) after execution to form samples of intent, strategy, and effect.
[0134] If KPI data deviates, the applicability weights, parameter ranges, or template selection strategies of the meta-operator library are updated to achieve closed-loop optimization. Preferably, the following update rules can be adopted:
[0135] (5)
[0136] in, For target weights or matching weights, To adjust the coefficient, This represents the weight or matching weight of the i-th target after the closed-loop update; This represents the weight or matching weight of the i-th target before the closed-loop update; This represents the target value, constraint threshold, or expected value corresponding to the i-th network performance metric in the structured intent. This represents the actual or evaluated value of the i-th network performance metric obtained through runtime monitoring after the strategy is executed.
[0137] like Figure 3 As shown, in this embodiment, the preferred implementation of meta-operator splitting, matching, and assembly is provided, specifically including:
[0138] Step D1, Intent Decomposition: Decompose the structured intent The requirements are divided into two categories: target requirements and constraint requirements. Target requirements include at least one or more of latency, bandwidth, and packet loss rate, while constraint requirements include at least thresholds, weights / priorities, business objects / scopes, and scenario labels.
[0139] Step D2, Semantic Matching Recall: Based on the intent field in the routing metaoperator library The candidate meta-operators are recalled, and the candidate meta-operators at least cover the action meta-operators and the check meta-operators.
[0140] Step D3, Reliability Consistency Verification: Perform precondition and capability boundary verification on the recalled candidate meta-operators, including: whether the required state meta-operator exists, whether the parameter range is available, and whether it conflicts with the existing network capabilities / policies; those that do not meet the requirements are eliminated or downgraded.
[0141] Step D4, Meta-operator Graph Assembly: Assemble the action meta-operators that have passed the consistency check into a meta-operator graph according to their dependencies. The preferred approach includes the following steps: candidate path generation → constraint filtering → multi-objective scoring → policy compilation → verification and rollback.
[0142] Step D5, Controlled Hint Construction and Controlled Generation: Based on the Meta-Operator Graph Output action whitelist and field schema to build controlled prompts The large language model is limited to the routing meta-operator library. DSL generation strategy within the boundaries defined by the schema This improves the controllability and verifiability of the output.
[0143] Step D6, Structured Feedback and Backfeedback of Failure Reasons: When the verification in Step 8 fails, the failure reason is encoded as structured feedback, such as: constraint unsatisfiable, capability not supported, conflict with the production network, field missing / type error, etc., and then processed according to... Figure 2 The process is fed back to step 6; when the failure is attributed to the failure of the meta-operator selection / dependency, it is further returned to step 5, and then enters the closed loop of steps 6 to 8.
[0144] A network routing meta-operator decomposition and intent matching system based on a large language model is proposed. This system can be deployed in various network scenarios, such as industrial IoT, medical networks, and data center networks. It uses an intent-driven routing engine as its core, collaborating with controllers / orchestrators, edge execution agents, and network devices / data planes to implement the aforementioned network routing meta-operator decomposition and intent matching method based on a large language model. Figure 4 As shown. An intent-driven routing engine includes at least the following functional modules:
[0145] The input acquisition and status fusion module is used to receive network status data such as user natural language routing intent, forms / logs / telemetry, and to complete field normalization, time alignment, anomaly handling and missing data completion to form a unified status view.
[0146] The intent parsing and structuring module is used to parse natural language intents into structured intents. It should include at least the following fields: business object / scope, target, constraint threshold, weight / priority, scenario label and confidence level.
[0147] The routing meta-operator library module is used to store the routing meta-operator library. Its dependencies, parameter ranges, and executable mapping rules.
[0148] Meta-operator matching and assembly module for use with structured intent With state element operator Complete meta-operator recall, semantic matching, dependency consistency verification and assembly, and output meta-operator graph. .
[0149] Controlled hint building module, used to build upon meta-operator graphs Generate controlled hints with whitelist / schema This limits the actions and fields that can be used in a large language model.
[0150] The strategy generation module, used for large language model reasoning, is based on controlled cues. Output structured strategy .
[0151] The policy verification and conflict detection module is used to verify structured policies. Performs structural verification, constraint consistency verification, capability executability verification, and conflict detection with existing network policies; generates structured feedback when failure occurs.
[0152] The strategy mapping and distribution module is used to map structured strategies. Mapping to control commands / configurations and issuing them to controllers / orchestrators or edge execution agents / network devices.
[0153] The operation monitoring and closed-loop update module is used to collect KPIs and logs / alarms / telemetry data, form intent, strategy, and effect samples, and update the meta-operator library, prompt templates, and weight parameters.
[0154] This invention enables the reuse of the same intent-driven routing engine in scenarios such as industrial IoT, medical networks, and data center networks. Policy distribution is accomplished through a controller / orchestrator, and rapid deployment is achieved through edge execution agents and network devices. Each scenario can be adapted through scenario tags, default weight / threshold policies, and verification strength configurations, preferably including:
[0155] In industrial IoT scenarios, the priority is to improve latency and packet loss rate, with bandwidth serving as the minimum guarantee. When the link fluctuates, priority is given to ensuring the connectivity of critical services and low-latency paths.
[0156] In healthcare network scenarios, implement stricter conflict detection and rollback strategies, and enable pre-deployment simulation assessment when necessary; the output must include interpretable fields for auditing.
[0157] In data center scenarios, improve bandwidth assurance and congestion bypass weights, and combine telemetry hotspot identification to quickly trigger regeneration; optional lightweight models for high-frequency decision distillation can be used by edge agents to reduce latency and call costs.
Claims
1. A method and system for network routing meta-operator decomposition and intent matching based on a large language model, which abstracts the target network into a graph. The set of network nodes Used to represent network devices and link sets. Used to represent directed links between nodes; for any candidate path The path metrics are defined to include at least latency. Available bandwidth Packet loss rate Its characteristics are, The routing intent is decomposed into computable and composable network routing meta-operators, including state meta-operators, target meta-operators, constraint meta-operators, action meta-operators, and validation meta-operators. Each meta-operator... It features standardized input / output, semantic description, applicable scenario labels, parameter range, pre- and post-dependencies, and executable mapping rules; thereby enabling the matching and combination of routing intents and meta-operator libraries, generating structured routing strategies, and mapping them to intent-driven routes that can be executed as network configurations. The steps include the following: S1: Obtain the user's natural language routing intent and network status data; preprocess and fuse the network status data to form a unified status view. ; S2 leverages the instruction-following capabilities and domain-specific constraints of a large language model to parse natural language routing intents and generate structured intent objects. ; S3, unify state view Abstracted as a set of state meta-operators ; S4, Building a routing meta-operator library And define a standardized data structure for each meta-operator; S5 will structure the intent object Split into a set of target meta-operators With the set of constraint meta-operators and with the routing meta-operator library Perform matching, generate a candidate set of meta-operators, and assemble them into a meta-operator graph. ; S6, based on the metaoperator graph Construct a controlled prompt template and inject structured intent fields, state meta-operator summaries, a list of allowed meta-operators, field constraints of the policy DSL, and security constraints to form a standardized controlled prompt. ; S7 will be controlled. Input a large language model and generate a structured routing strategy. ; S8, for structured routing policies Perform verification and risk control; When verification fails or conflict detection triggers a risk threshold, a structured failure reason and correction suggestions are generated and fed back to step S6 to rebuild the prompt before generating the structured routing policy. Until the verification passes or the rollback strategy is triggered; If the verification passes, proceed to step S9; S9 will pass the verification of the structured routing policy. Mapped to control commands / configurations that can be executed by network devices or controllers, and then issued and executed through the interface; S10 continuously monitors latency, bandwidth, and packet loss rate after execution to form samples of intent, strategy, and effect. If the monitoring data shows deviation, update the applicability weights, parameter ranges, or prompt the template selection strategy of the meta-operator library.
2. The network routing meta-operator decomposition and intent matching method based on a large language model according to claim 1, characterized in that, The network status data includes at least one or more of the following: form data, log data, telemetry monitoring data, topology and link attribute data, and device capability and current network policy data.
3. The network routing meta-operator decomposition and intent matching method based on a large language model according to claim 1, characterized in that, The structured intent object It should include at least: business object / scope field, multi-objective field, constraint field, scenario label field, confidence and disambiguation field.
4. The network routing meta-operator decomposition and intent matching method based on a large language model according to claim 1, characterized in that, Set of state meta-operators It includes at least: topology status meta-operators, link metric meta-operators, congestion queue meta-operators, fault alarm meta-operators, and device capability meta-operators, and adds a timestamp and credibility tag to each status meta-operator.
5. The network routing meta-operator decomposition and intent matching method based on a large language model according to claim 1, characterized in that, The standardized data structure includes at least: meta-operator identifier, type, semantic description, input parameter definition, output field definition, applicable scenario label, parameter range, prerequisite dependencies, executable mapping rules, and risk level marker.
6. The network routing meta-operator decomposition and intent matching method based on a large language model according to claim 1, characterized in that, Meta-operator matching and assembly includes the following steps: S51, perform initial screening based on scene labels and meta-operator types to obtain a candidate set. ; S52, Encode the intent field description into a vector representation. The semantic description of the meta-operator is encoded as a vector representation. Calculate semantic similarity and sort them from highest to lowest similarity; the calculation is as follows: , in, Represents the routing meta-operator library The k-th candidate meta-operator in; Represents a structured intent object With candidate meta-operators The semantic similarity is used to measure the degree of matching between the current intent and the candidate meta-operator; S53, perform precondition checks on candidate meta-operators and generate dependency consistency scores. Prerequisites include whether the required state meta-operator exists, whether the parameter range is available, and whether it conflicts with the existing network capabilities. S54. Based on semantic similarity and dependency consistency scores, calculate the matching score and select the Top-K meta-operator with the highest score: , in, , These are weighting coefficients, configured according to the scenario. For matching scores; Step 55: Based on the meta-operator dependencies, assemble the action meta-operators into a meta-operator graph in the order of candidate path generation, constraint filtering, multi-objective scoring, policy compilation, verification rollback, and executable mapping. or meta-operator sequence It also generates parameter suggestions and strategy skeletons.
7. The network routing meta-operator decomposition and intent matching method based on a large language model according to claim 1, characterized in that, Structured routing strategy The verification includes at least: structural legality verification, constraint consistency verification, executability verification, and conflict detection; For candidate paths The hard constraint verification is expressed as: , in, This represents the corresponding time delay constraint threshold in the structured intent. This represents the available bandwidth constraint threshold corresponding to the structured intent. This represents the packet loss rate constraint threshold corresponding to the structured intent. Indicates time delay. Indicates available bandwidth. Indicates packet loss rate; The candidate path set satisfying the hard constraints is then ranked according to multiple objectives; the comprehensive cost is calculated after normalizing the indicators. : , in, , , Derived from intent weights or scenario default weights; , , These represent the results after normalizing latency, packet loss rate, and available bandwidth, respectively.
8. The network routing meta-operator decomposition and intent matching method based on a large language model according to any one of claims 1-7, characterized in that, Controlled prompts The following conditions must be met at least: The output must be in policy DSL format; Only action meta-operators and fields declared in the meta-operator library are allowed to be referenced; The critical threshold constraints must not be relaxed; For uncertainties, a confidence level or alternative solutions must be output.
9. A network routing meta-operator decomposition and intent matching system based on a large language model, used to execute the method as described in any one of claims 1-7, characterized in that, Deployed in multi-scenario networks, it takes an intent-driven routing engine as its core and works in collaboration with controllers / orchestrators, edge execution agents, and network devices / data planes. The intent-driven routing engine includes: The input acquisition and status fusion module is used to receive the user's natural language routing intent and network status data, and to complete field normalization, time alignment, anomaly handling and missing data completion to form a unified status view. The intent parsing and structuring module is used to parse natural language intents into structured intents. ; The routing meta-operator library module is used to store the routing meta-operator library and its dependencies, parameter ranges, and executable mapping rules; Meta-operator matching and assembly module for use with structured intent With state element operator Complete meta-operator recall, semantic matching, dependency consistency verification and assembly, and output meta-operator graph. ; Controlled hint building module, used to build upon meta-operator graphs Generate controlled hints with whitelists / schemas to limit the actions and fields that can be used by large language models; The policy generation module is used for reasoning in large language models, and outputs structured policies based on controlled cues. ; The policy verification and conflict detection module is used to verify structured policies. Performs structural verification, constraint consistency verification, capability executability verification, and conflict detection with existing network policies; generates structured feedback upon failure. The strategy mapping and distribution module is used to map structured strategies. Mapped to control commands / configurations and distributed to controllers / orchestrators or edge execution agents / network devices; The operation monitoring and closed-loop update module is used to collect latency, bandwidth, packet loss rate and logs / alarms / telemetry data, form intent, strategy and effect samples, and update the meta-operator library, prompt templates and weight parameters.