An Intent-Driven Translation Method Based on GraphRAG

Abstract

This invention discloses a GraphRAG-based method for translating network control intentions, aiming to solve problems in existing technologies such as insufficient intention understanding, lack of global context awareness, difficulty in knowledge updating, and inability to handle complex reasoning. This invention achieves accurate, context-aware, and highly reliable automated translation of network intentions by constructing a dynamic network knowledge graph and combining graph retrieval and large language model generation techniques. The scheme includes the following steps: for autonomous communication networks, establishing and maintaining a two-layer dynamic network knowledge graph that simultaneously represents the network's static knowledge and dynamic state; performing community detection and constructing a summary index on the two-layer dynamic network knowledge graph; receiving natural language network intentions input by the user and performing context-enhanced retrieval based on the two-layer dynamic network knowledge graph; and generating network configuration strategies and implementing closed-loop feedback based on the enhanced context.

Description

Technical Field

[0001] This invention relates to the field of network automation technology, and more specifically to an intent-driven translation method based on GraphRAG. Background Technology

[0002] Traditional network management relies heavily on manual operation by network engineers, configuring network devices such as routers and switches one by one via the command-line interface (CLI). This approach is not only labor-intensive and inefficient, but also significantly increases the risk of configuration errors in today's increasingly complex and large-scale network environments, making it difficult to meet the demands of modern businesses for network agility, reliability, and rapid response.

[0003] To address these challenges, a new networking paradigm—Intent-Driven Networking (IDN)—has emerged and is considered the core paradigm for next-generation network automation. The core idea of ​​IDN is to allow network administrators or users to describe their business objectives in a high-level, declarative way (i.e., "intents"), such as "ensuring the quality of video conferencing from Beijing to Shanghai." IDN automatically translates these intents into detailed network configurations, making the network more reliable and efficient. It also shields users from the underlying network technologies, significantly reducing the operational complexity for network users and services.

[0004] Early intent translation techniques primarily relied on predefined keyword templates and rule engines. This method triggered fixed configuration processes by matching specific words in the user's intent (such as "create," "bandwidth," and "ACL"). However, it lacked flexibility, struggled to handle colloquial or semantically ambiguous expressions that exceeded predefined rule templates, and had high rule base maintenance costs, making it difficult to adapt to the rapid development of network technology and services. With the advancement of Natural Language Processing (NLP) technology, researchers began using models such as Named Entity Recognition (NER) (e.g., BiLSTM-CRF, BERT) to extract key information (such as source address, destination address, and service type) from intents. This method improved in understanding the diverse expressions of intents, but it still essentially relied on pattern learning from labeled data, resulting in poor generalization ability and an inability to handle real-time network conditions, potentially leading to generated policies that did not reflect the actual network situation. In recent years, Large Language Models (LLMs) have been introduced into the field of intent translation due to their powerful semantic understanding and reasoning capabilities. To address the potential "illusion" problem of LLMs, researchers have introduced Retrieval Enhanced Generation (RAG) technology. Before performing intent translation, this technology first retrieves relevant fragments from external knowledge bases (such as equipment manuals and technical documents) as context for the LLM, thereby enhancing the accuracy of the generated results. However, existing RAG technologies can disrupt the structured relationships of knowledge, leading to a lack of internal relationships. Furthermore, when faced with abstract and complex intents, it is unable to effectively associate and reason with multi-hop information, resulting in an incomplete understanding of the intent.

[0005] In summary, existing intent translation methods, ranging from simple rule matching to natural language processing techniques and traditional RAG techniques, have failed to adequately address the challenge of deeply integrating user intent with dynamic, structured global network knowledge. Existing technologies are either too rigid or lack a deep understanding of network relationships, resulting in translation accuracy, reliability, and intelligence levels that are insufficient to meet the requirements of next-generation autonomous networks when dealing with complex, dynamic intents requiring global context. Summary of the Invention

[0006] In view of this, the present invention provides a GraphRAG-based method for translating network control intents, aiming to solve the problems of insufficient intent understanding, lack of global context awareness, difficulty in knowledge updating, and inability to handle complex reasoning in existing technologies. The present invention achieves accurate, context-aware, and highly reliable automated translation of network intents by constructing a dynamic network knowledge graph and combining graph retrieval and large language model generation technologies.

[0007] To achieve the above objectives, the technical solution of the present invention includes the following steps:

[0008] Step 1: For autonomous communication networks, establish and maintain a two-layer dynamic network knowledge graph that can simultaneously represent the network's static knowledge and dynamic state.

[0009] Step 2: Perform community detection on the two-layer dynamic network knowledge graph and construct a summary index.

[0010] Step 3: Receive the natural language network intent input by the user, and perform context-enhanced retrieval based on the two-layer dynamic network knowledge graph.

[0011] Step 4: Based on the enhanced context, generate network configuration policies and implement closed-loop feedback.

[0012] Furthermore, the two-layer dynamic network knowledge graph includes a physical topology layer knowledge graph and a knowledge concept layer knowledge graph. The physical topology layer knowledge graph is used to represent the dynamic state of the network, while the knowledge concept layer knowledge graph is used to represent the static knowledge of the network.

[0013] Furthermore, the physical topology layer knowledge graph includes entity nodes and dynamic status information obtained in real time from the SDN controller of the network monitoring system; the entity nodes include specific physical devices, interfaces, and link topologies in the autonomous communication network; the dynamic status information includes link latency, bandwidth utilization, and packet loss rate attributes.

[0014] The knowledge graph data for the knowledge concept layer comes from unstructured static knowledge documents, where entity nodes are technical concepts and relation edges represent logical dependencies and causal relationships between concepts.

[0015] Furthermore, in step 1, the specific steps for establishing and maintaining the two-layer dynamic network knowledge graph are as follows: Step 1.1: Data collection and processing, specifically: data sources include PDF documents such as equipment configuration manuals and operation and maintenance experience, and PyMuPDF is used to extract the data.

[0016] Step 1.2: Perform data cleaning, specifically: deduplicate text records by calculating their hash values, keep only one record with the same hash value, and remove useless information such as headers, footers, and special symbols.

[0017] Step 1.3: Perform text segmentation, specifically: divide the cleaned text block into text blocks according to periods, newlines, etc. Set the maximum number of tokens in each text block to 512, and the number of overlapping tokens between adjacent blocks to 50.

[0018] Step 1.4: Extract entities and relationships. Specifically, construct reasonable prompt words through few-shot learning to guide the large model to extract entity nodes from text blocks, including "configuration commands" and "business indicators", and identify logical relationships. Construct triples (entity node A, logical relationship, entity node B) to form a knowledge graph of the knowledge concept layer and store it in the Neo4j graph database.

[0019] Among them, few-shot learning refers to providing some labeled entity extraction or entity attribute extraction examples in the prompt words to help large models understand the extraction task.

[0020] Step 1.5: Entity resolution and disambiguation, specifically: Obtain all entities contained in the triples in the Neo4j graph database, use the Embedding model to convert all entity names into high-dimensional vectors, and then filter candidate similar pairs by calculating the cosine similarity between entity vectors; for any two entity nodes A and B, the cosine similarity calculation formula is:

[0021] Where x represents the high-dimensional semantic feature vector of entity node A after transformation by the embedding model, y represents the high-dimensional semantic feature vector of entity node B after transformation by the embedding model, and · represents the inner product of vectors. The norm of a vector It represents the angle between two vectors.

[0022] When the calculated cosine similarity exceeds the threshold, the two entities are considered as candidate pairs and submitted to the LLM for the final merging decision, ensuring that each entity is uniquely and correctly represented in the knowledge graph and preventing duplicate or incorrect associations.

[0023] Step 1.6: Construction of the physical topology layer knowledge graph, specifically: First, discover physical connections based on the LLDP protocol and construct device nodes and link edges; second, parse the network device's runtime configuration file, extract key configuration items as static attributes and write them to the nodes; finally, through the SDN controller, collect real-time performance indicators of core links in the network every 30 seconds, including link topology, bandwidth utilization, latency, jitter, and packet loss rate, and update the acquired dynamic data to the physical topology layer knowledge graph in real time.

[0024] Furthermore, step 2 specifically includes the following steps: Step 2.1: Apply the community detection algorithm to the physical topology layer knowledge graph to generate a regional situation summary describing the health and policy status of the regional network.

[0025] A community detection algorithm is applied to the knowledge graph at the knowledge concept layer to generate a domain knowledge summary that summarizes specific technical topics.

[0026] Step 2.2: Vectorize the two types of summaries and construct a vector index that supports efficient similarity search.

[0027] Further, step 2.1, specifically, is as follows: The Leiden community detection algorithm is used to perform community partitioning on the knowledge graph at the knowledge concept layer and the physical topology layer constructed in step 1. The goal of this algorithm is to maximize the network modularity Q, which is defined as:

[0028] in, It is the total number of edges in the graph. These are elements of the adjacency matrix, representing entity nodes. and Is there an edge between them? and It is a physical node and The degree, and It is a physical node and The community to which it belongs It is an indicator function, when It is 1 if it is true, otherwise it is 0.

[0029] After executing the community detection algorithm, the knowledge graph was divided into A collection of communities

[0030] Each community The internal nodes are all closely connected, representing a highly cohesive functional or logical unit in the network.

[0031] Among them, the knowledge graph generated at the knowledge concept layer contains different technical topic clusters, and the generated summary describes the relevant configurations of the specific technologies involved.

[0032] The physical topology layer knowledge graph, whose community partitioning results include logical regions in the real network, generates a summary describing the network architecture, operating protocols, and global policy preferences of that region.

[0033] Further, step 2.2, specifically, is as follows: Input all entities, relationships, and key attributes within the community into the LLM, and use prompts to define each community. Generate a text summary The generated text summary is then vectorized using the Embedding model and stored in the vector database FAISS to build a vector index that supports efficient similarity search.

[0034] Further, step 3 includes the following steps: Step 3.1: Use LLM to perform preliminary parsing of the natural language intent input by the user and identify the key entities in the intent.

[0035] Step 3.2: A constraint-aware multidimensional hybrid retrieval strategy is adopted to construct a complete context subgraph containing business features, equipment specifications, and physical status.

[0036] Step 3.3: Input the result obtained in step 3.2 into the LLM for evaluation to determine whether the information is sufficient to generate a strategy. If the result is no, continue to execute step 3.2. If the result is yes, use the LLM to integrate all the information collected during the loop into a final context subgraph.

[0037] Furthermore, the multi-dimensional hybrid retrieval strategy is as follows: Macro-architecture retrieval: Based on user intent, the system first retrieves the architectural features and configuration specifications of network regions from the summary index of the two-layer knowledge graph, extracts the best technical implementation path for responding to intent, and uses it as a global constraint for subsequent retrieval.

[0038] Physical state retrieval: Using key entities involved in the intent as anchor points, perform multi-hop path search in the physical topology layer graph to obtain the topological connections between relevant nodes, as well as SDN data on relevant paths, and at the same time obtain the specific device models involved on the paths.

[0039] Equipment specification retrieval: Based on the specific equipment model determined by physical status retrieval and the technical path determined by macro-architecture retrieval, the corresponding configuration manual summary and command template are retrieved in the knowledge concept layer graph to obtain the correct command syntax and parameters.

[0040] Furthermore, step 4 specifically includes the following steps: Step 4.1: Serialize the final context subgraph obtained in Step 3 into an LLM-readable text format and combine it with the user's original intent to form an enhanced prompt.

[0041] Step 4.2: Input the prompt generated in Step 4.1 into the LLM, and instruct it to generate a network configuration policy that meets the intent requirements and conforms to the current network status through the corresponding prompt word template.

[0042] Step 4.3: Distribute the generated policy to network devices for execution, monitor the changes in network status after execution, and feed the changes back to the knowledge graph in Step 1 to form an automated closed loop.

[0043] Beneficial effects: 1. This invention innovatively proposes a hybrid retrieval strategy that combines structured retrieval and semantic retrieval by combining a large language model with a real-time dynamic network knowledge graph. Unlike traditional methods that rely solely on single keyword matching or vector retrieval, this invention can fully utilize the real-time topology and state information of the network while deeply understanding user intent, thus solving the problem that traditional methods cannot handle complex reasoning and adapt to dynamic changes.

[0044] 2: This invention proposes an iterative evaluation and feedback update mechanism based on a large language model. Compared with the "one-time" retrieval mode of traditional RAG, before generating a strategy, the large language model can autonomously evaluate whether the current information is complete and automatically supplement the query for missing information. This dynamic feedback mechanism greatly improves the quality of the final generated strategy and the ability to handle complex tasks, effectively avoids the large model illusion problem caused by missing information, and significantly improves the automation and intelligence level of network management. Attached Figure Description

[0045] Figure 1 A flowchart for constructing and detecting network knowledge graphs; Figure 2 A flowchart for hybrid retrieval and closed-loop feedback; Figure 3 This is a flowchart of the hybrid retrieval module. Detailed Implementation

[0046] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0047] This invention provides a GraphRAG-based method for translating network control intentions, specifically applicable to large-scale autonomous communication networks. The physical nodes in the network refer to physical device nodes such as routers, switches, and access gateways. Large-scale autonomous communication networks typically have a logical topology of tens to hundreds of nodes or more, and are characterized by high-frequency dynamic traffic fluctuations and diverse service requirements. The method includes the following steps: Step 1: Establish and maintain a network knowledge graph that can simultaneously represent both static and dynamic states of the network. This consists of the following specific steps: Step 1.1: Data Collection and Processing: Data sources include PDF documents such as equipment configuration manuals and operation and maintenance experience, which are extracted using PyMuPDF.

[0048] Step 1.2: Data cleaning: Deduplication is performed by calculating the hash value of text records. Only one record with the same hash value is kept, and useless information such as headers, footers, and special characters is removed.

[0049] Step 1.3: Text Segmentation: Segment the cleaned text block into text blocks according to periods, newlines, etc. Set the maximum number of tokens in each text block to 512, and the number of overlapping tokens between adjacent blocks to 50.

[0050] Step 1.4: Extract entities and relationships: Construct reasonable prompt words through few-shot learning to guide the large model to extract entities such as "configuration command" and "business indicators" from text blocks, and identify logical relationships such as "depends on" and "leads to", construct triples (entity A, logical relationship, entity B) to form a knowledge graph of the knowledge concept layer and store it in the Neo4j graph database.

[0051] Few-shot learning refers to providing labeled examples of entity extraction or entity attribute extraction in the prompt words to help large models better understand the extraction task. In this invention, manually labeled domain knowledge extraction examples (including typical network text blocks and their corresponding standard triplet formats) are selected as prompt words for large language models to standardize the knowledge extraction format of LLM and improve the accuracy of recognition and relation construction of complex network technical logic (such as protocol dependencies and configuration causal relationships).

[0052] Step 1.5: Entity Resolution and Disambiguation: Obtain all entities contained in the triples in the Neo4j graph database. Use the Embedding model (all-MiniLM-L6-v2 in this invention) to convert all entity names into high-dimensional vectors. Then, filter candidate similarity pairs by calculating the cosine similarity between entity vectors. For any two entities A and B, the cosine similarity calculation formula is:

[0053] Where x and y represent the high-dimensional semantic feature vectors of entities A and B after transformation by the Embedding model, and · represents the inner product of the vectors. The norm of a vector It represents the angle between two vectors.

[0054] When the calculated cosine similarity exceeds the threshold, the two entities are considered as candidate pairs and submitted to the LLM for the final merging decision, ensuring that each entity is uniquely and correctly represented in the knowledge graph and preventing duplicate or incorrect associations.

[0055] Step 1.6: Dynamic Physical Topology Layer Construction: First, physical connections are discovered based on the LLDP protocol, and device nodes and link edges are constructed; second, the running configuration files of network devices are parsed, and key configuration items (such as running protocols and device roles) are extracted and written as static attributes to the nodes; finally, through the SDN controller, real-time performance indicators of core links in the network are collected every 30 seconds, mainly including link topology, bandwidth utilization, latency, jitter, and packet loss rate, and the acquired dynamic data is updated to the knowledge graph in real time.

[0056] This invention constructs a comprehensive "two-layer dynamic graph," addressing the problem of "separation between physical state and logical knowledge" in existing technologies. Traditional solutions mostly rely on static document libraries (such as manuals and SLAs) for retrieval, lacking awareness of real-time network physical states (such as topology changes and link congestion). This results in configurations that, while grammatically compliant, are infeasible in the physical network (e.g., configured paths but insufficient link bandwidth), or only consider network state and user intent, lacking structured management and retrieval of operational knowledge. This invention innovatively constructs a two-layer graph comprising a "physical topology layer" and a "knowledge concept layer," and dynamically injects real-time operational status (bandwidth, latency, etc.) into the physical layer using SDN telemetry technology. This design enables the intent translation process to not only acquire static configuration knowledge but also perceive the dynamic physical environment in real time, ensuring that the generated strategies are physically feasible and significantly improving configuration success rate and network reliability.

[0057] Step 2: Community segmentation and summary index construction of the knowledge graph, as detailed below: Step 2.1: The Leiden community detection algorithm is used to perform community partitioning on the knowledge graphs constructed in Step 1 at the knowledge concept layer and physical topology layer. The goal of this algorithm is to maximize the network modularity Q, which is defined as:

[0058] in, It is the total number of edges in the graph. These are elements of the adjacency matrix, representing entity nodes. and Is there an edge between them? and It is a physical node and The degree, and It is a physical node and The community to which it belongs It is an indicator function, when It is 1 if it is true, otherwise it is 0.

[0059] After executing the community detection algorithm, the map was divided into A collection of communities

[0060] Each community The internal nodes are all closely connected, representing a highly cohesive functional or logical unit in the network.

[0061] Among them, the communities generated by the knowledge concept layer include different technical topic clusters (such as "OSPF routing protocol cluster", "QoS service quality cluster", "ACL security policy cluster"); the physical topology layer, the community division results include logical areas in the real network (such as data center area, wide area network backbone area, campus access area).

[0062] Step 2.2: Input all entities, relationships, and key attributes within the community into the LLM, using prompts to assign them to each community. Generate a text summary The generated text summary is then vectorized using the Embedding model and stored in the vector database FAISS to build a vector index that supports efficient similarity search.

[0063] Specifically, the summary generated at the knowledge concept layer focuses on describing the relevant configurations of the specific technologies involved (e.g., "Configuring MPLS VPN requires completing the following in sequence: IGP interconnection, LDP neighbor establishment, BGP VPNv4 neighbor establishment, and VRF instance binding"); the summary generated at the physical topology layer focuses on describing the network architecture of the area (e.g., "Spine-Leaf architecture"), the operating protocol (e.g., "Enable OSPF Area 0 across the entire network"), and global policy preferences (e.g., "Prioritize video traffic").

[0064] This step introduces a "community summary" and "hybrid retrieval" mechanism, addressing the problems of "lack of macro-architectural understanding" and "low retrieval accuracy" in existing technologies. Traditional RAG vector retrieval based on text slices is prone to getting bogged down in micro-details and lacks a macro-level understanding of the overall network architecture (such as regional strategies and networking modes), leading to potential conflicts between generated local configurations and global strategies. Furthermore, when faced with complex intents, directly retrieving massive amounts of documents can easily introduce noise, resulting in inaccurate retrieval results. This invention utilizes the Leiden community detection algorithm to generate architectural summaries of network regions and employs a hybrid retrieval strategy of "macro-architectural navigation to physical state verification to micro-instruction matching." The system first determines the technical path (such as MPLS) through the macro-summary, and then performs physical verification and instruction matching based on this path. This "direction first, details later" strategy effectively eliminates ambiguity, avoids conflicts between local configurations and global specifications, and significantly improves the accuracy of intent translation and architectural consistency.

[0065] Figure 1 A flowchart illustrating the construction of a network knowledge graph and community detection process is provided.

[0066] Step 3: After receiving the user's natural language intent (e.g., "Ensure the quality of video conferencing from Beijing to Shanghai"), perform context-enhanced retrieval, as follows: Step 3.1: Use LLM to parse the user's input intent and identify the key network entities. For example, in "ensure the quality of video conferencing from Beijing to Shanghai", the following can be identified: source address (Beijing), destination address (Shanghai), service type (video conferencing), and service quality requirement (high).

[0067] Step 3.2: Employ a constraint-aware multidimensional hybrid retrieval strategy to retrieve contextual information from the knowledge graph and community summary, and integrate the retrieval results into a contextual subgraph, which includes directly related network paths, devices, strategies, and macroscopically related network region states.

[0068] The constraint-aware multidimensional hybrid retrieval strategy is as follows: Macro-architecture retrieval: Using the Embedding model, key entities in the obtained user intent are encoded into vectors. K-nearest neighbor retrieval is performed in the community summary index constructed in step 2. By calculating the cosine similarity score, the community summary most similar to the user intent is matched, and the top-k communities with the highest scores are selected. The community summaries corresponding to the top-k communities are used as the context of the retrieval results and input into the large language model for semantic analysis. From this, the key technical architecture features (e.g., 'using MPLS VPN') and policy specifications of the current network area are extracted and transformed into key technical constraints required for subsequent physical state retrieval.

[0069] Physical Status Retrieval: Using the entities extracted in step 3.1 as anchor points, a graph query is performed in the physical topology layer knowledge graph to find all possible paths connecting network devices related to "Beijing" and "Shanghai". Based on the architectural constraints obtained from the macro-architecture retrieval, the K-Shortest Paths algorithm is executed in the physical topology layer graph to find all feasible physical paths. The real-time status (latency, packet loss rate, etc.) of each interface on the path is read, and the best path that meets the intent requirements is returned. At the same time, the specific model information of all devices involved in the preferred path (such as Huawei NE40E, Cisco Nexus9k) is obtained as a key index for the third-level retrieval of device specifications.

[0070] Equipment specification retrieval: Using the technical constraints determined by macro-architecture retrieval (such as MPLS) and the specific equipment model locked by physical dimension retrieval (such as Huawei NE40E) as joint query conditions, a precise search is performed in the knowledge concept layer graph and related document library to locate the configuration command template and parameter rules corresponding to the specific equipment model. This ensures that the final generated instruction set conforms to both the syntax specifications of the physical equipment and the business requirements of the macro-architecture. Step 3.3: The LLM-driven iterative evaluation and information integration of the results returned in Step 3.2 is performed. A specific prompt word template is constructed, and the context subgraph generated in Step 3.2 is input into the LLM, which is then asked: "Is the current information sufficient to generate a complete, reliable, and conflict-free network policy to meet the user's intent?" If the LLM returns "yes," the loop ends, and the process proceeds to Step 4. If the return is "no," the LLM provides the reason, updates the query, and returns to Step 3.2 to supplement the missing information and update the context subgraph until the LLM evaluation deems the information sufficient or the preset maximum number of loops is reached. The current optimal context information is then output, and potential uncertainties are identified. If an irreconcilable hard conflict is found between physical resources and business requirements (such as a physical link being physically disconnected), a "Cannot meet intent" feedback report is generated, and the translation process terminates, rather than forcibly generating a misconfiguration.

[0071] The prompt word template specifically instructs the LLM to act as a network expert, judging the completeness, consistency, and relevance of the current information. The core criteria for judgment include: whether the physical topology path is complete, whether real-time status data of key network elements (such as bandwidth, packet loss rate, latency, etc.) are missing, and whether the user intent is mapped to specific configuration parameters (such as VLAN ID, bandwidth value).

[0072] The specific method for updating queries based on LLM feedback is as follows: If the feedback indicates a lack of real-time status data, a status query instruction for a specific device entity is generated to obtain the latest SDN monitoring data from the knowledge graph; if the feedback suggests incomplete relationships or paths between entities, a graph database query statement is generated, and multi-hop path search and adjacency node lookup are performed in the knowledge graph to complete the topology; if the feedback points out that the business concept is vague, the concept is transformed into new keywords, and a vector semantic query is generated to retrieve the document with the highest similarity in the vector index.

[0073] Step 4: Based on the final context subgraph returned in Step 3, LLM generates a network configuration strategy and implements closed-loop feedback, as follows: Step 4.1: Serialize the context subgraph finally obtained in Step 3 into an LLM-readable text format, and then combine the text with the user's original intent to form a structured and information-rich enhanced prompt.

[0074] Step 4.2: Input the enhanced prompts obtained in Step 4.1 into the LLM. Using the designed prompt template, the LLM is instructed to generate specific, executable network configuration policies based on the provided comprehensive context (including the current network status and user requirements).

[0075] Step 4.3: Deploy the LLM-generated policy to the network controller for execution. Simultaneously, the network monitoring system continuously monitors network status changes after policy execution (e.g., whether the latency of the Beijing-Shanghai path has decreased). These changes will serve as new dynamic information, feeding back in real-time and updating the knowledge graph from Step 1. This feedback process forms an automated closed loop, enabling the knowledge graph to continuously learn and evolve, thereby providing more accurate context for the next intent translation.

[0076] This step establishes an iterative evaluation and feedback update mechanism, which solves the problems of "lack of self-correction capability" and "inability to adapt to dynamic network changes" in existing technologies.

[0077] Existing technologies are mostly one-way generation modes, which end once the configuration is distributed. They lack verification of the generation results and monitoring of the execution effect. Once a configuration error or a sudden change in network status occurs, the system cannot automatically detect and adjust.

[0078] The iterative evaluation and feedback update mechanism based on a large language model proposed in this invention enables the large language model to autonomously evaluate whether the current information is complete before generating the strategy, and automatically supplement the query for missing information. After the strategy is executed, the system monitors the changes in network status and writes them back to the graph. This scheme can flexibly respond to the dynamic changes in the network environment and achieve closed-loop control.

[0079] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A GraphRAG-based network management intent translation method, characterized in that, Includes the following steps: Step 1: For autonomous communication networks, establish and maintain a two-layer dynamic network knowledge graph that can simultaneously represent the network's static knowledge and dynamic state. Step 2: Perform community detection on the two-layer dynamic network knowledge graph and construct a summary index; Step 3: Receive the user's input of natural language network intent, and perform context-enhanced retrieval based on the two-layer dynamic network knowledge graph; Step 4: Based on the enhanced context, generate network configuration policies and implement closed-loop feedback.

2. The GraphRAG-based network management intent translation method of claim 1, wherein, The two-layer dynamic network knowledge graph includes a physical topology layer knowledge graph and a knowledge concept layer knowledge graph. The physical topology layer knowledge graph is used to represent the dynamic state of the network, and the knowledge concept layer knowledge graph is used to represent the static knowledge of the network.

3. The GraphRAG-based network management intent translation method of claim 2, wherein, The physical topology layer knowledge graph includes entity nodes and dynamic status information obtained in real time from the SDN controller of the network monitoring system; the entity nodes include specific physical devices, interfaces, and link topologies in the autonomous communication network; the dynamic status information includes link latency, bandwidth utilization, and packet loss rate attributes. The knowledge graph data for the knowledge concept layer comes from unstructured static knowledge documents, where entity nodes are technical concepts and relation edges represent logical dependencies and causal relationships between concepts.

4. The GraphRAG-based network management intent translation method of claim 3, wherein, In step 1, the specific steps for establishing and maintaining the two-layer dynamic network knowledge graph are as follows: Step 1.1: Data collection and processing, specifically: data sources include PDF documents such as equipment configuration manuals and operation and maintenance experience, and PyMuPDF is used to extract them; Step 1.2: Perform data cleaning, specifically: deduplicate text records by calculating their hash values, keep only one record with the same hash value, and remove useless information such as headers, footers, and special characters; Step 1.3: Perform text segmentation, specifically: divide the cleaned text block into text blocks according to periods, newlines, etc., set the maximum number of tokens in each text block to 512, and the number of overlapping tokens between adjacent blocks to 50; Step 1.4: Extract entities and relationships. Specifically, construct reasonable prompt words through few-shot learning to guide the large model to extract entity nodes from text blocks, including "configuration commands" and "business indicators", and identify logical relationships. Construct triples (entity node A, logical relationship, entity node B) to form a knowledge graph of the knowledge concept layer and store it in the Neo4j graph database. Among them, few-shot learning refers to providing some labeled entity extraction or entity attribute extraction examples in the prompt words to help large models understand the extraction task; Step 1.5: Entity resolution and disambiguation, specifically: Obtain all entities contained in the triples in the Neo4j graph database, use the Embedding model to convert all entity names into high-dimensional vectors, and then filter candidate similar pairs by calculating the cosine similarity between entity vectors; for any two entity nodes A and B, the cosine similarity calculation formula is: wherein x represents the high-dimensional semantic feature vector of the entity node A after conversion by the Embedding model, y represents the high-dimensional semantic feature vector of the entity node B after conversion by the Embedding model, and · represents the inner product of vectors, denotes the norm of a vector, denotes the included angle between two vectors; When the calculated cosine similarity exceeds the threshold, the two entities are considered as candidate pairs and submitted to the LLM for the final merging decision, ensuring that each entity is uniquely and correctly represented in the knowledge graph and preventing duplicate or incorrect associations. Step 1.6: Construction of the physical topology layer knowledge graph, specifically: First, discover physical connections based on the LLDP protocol and construct device nodes and link edges; second, parse the network device's runtime configuration file, extract key configuration items as static attributes and write them to the nodes; finally, through the SDN controller, collect real-time performance indicators of core links in the network every 30 seconds, including link topology, bandwidth utilization, latency, jitter, and packet loss rate, and update the acquired dynamic data to the physical topology layer knowledge graph in real time.

5. The network control intent translation method based on GraphRAG as described in claim 1, characterized in that, Step 2 specifically includes the following steps: Step 2.1: Apply a community detection algorithm to the physical topology layer knowledge graph to generate a regional situation summary describing the health and policy status of the regional network; A community detection algorithm is applied to the knowledge graph at the knowledge concept layer to generate a domain knowledge summary that summarizes specific technical topics; Step 2.2: Vectorize the two types of summaries and construct a vector index that supports efficient similarity search.

6. The network control intent translation method based on GraphRAG as described in claim 5, characterized in that, Step 2.1, specifically, involves the following steps: The Leiden community detection algorithm is used to perform community partitioning on the knowledge graph at the knowledge concept layer and the physical topology layer constructed in step 1. The goal of this algorithm is to maximize the network modularity Q, which is defined as: in, It is the total number of edges in the graph. These are elements of the adjacency matrix, representing entity nodes. and Is there an edge between them? and It is a physical node and The degree, and It is a physical node and The community to which it belongs It is an indicator function, when The value is 1 if it is true, and 0 otherwise. After executing the community detection algorithm, the knowledge graph was divided into A collection of communities Each community The internal nodes are all closely connected, representing a highly cohesive functional or logical unit in the network; Among them, the knowledge graph generated at the knowledge concept layer contains different technical topic clusters, and the generated summary describes the relevant configurations of the specific technologies involved; The physical topology layer knowledge graph, whose community partitioning results include logical regions in the real network, generates a summary describing the network architecture, operating protocols, and global policy preferences of that region.

7. The network control intent translation method based on GraphRAG as described in claim 6, characterized in that, Step 2.2, specifically, involves the following steps: Input all entities, relationships, and key attributes within the community into the LLM, and use prompts to define each community. Generate a text summary The generated text summary is then vectorized using the Embedding model and stored in the vector database FAISS to build a vector index that supports efficient similarity search.

8. The network control intent translation method based on GraphRAG as described in claim 1, characterized in that, Step 3 includes the following steps: Step 3.1: Use LLM to perform preliminary parsing of the natural language intent input by the user and identify the key entities in the intent; Step 3.2: A constraint-aware multidimensional hybrid retrieval strategy is adopted to construct a complete context subgraph containing business features, equipment specifications, and physical status; Step 3.3: Input the result obtained in step 3.2 into the LLM for evaluation to determine whether the information is sufficient to generate a strategy. If the result is no, continue to execute step 3.

2. If the result is yes, use the LLM to integrate all the information collected during the loop into a final context subgraph.

9. A network control intent translation method based on GraphRAG as described in claim 8, characterized in that, The multidimensional hybrid retrieval strategy is as follows: Macro-architecture retrieval: Based on user intent, the system first retrieves the architectural features and configuration specifications of network regions from the summary index of the two-layer knowledge graph, and extracts the best technical implementation path for responding to the intent as a global constraint for subsequent retrieval. Physical state retrieval: Using key entities involved in the intent as anchor points, perform multi-hop path search in the physical topology layer graph to obtain the topological connections between relevant nodes, as well as SDN data on relevant paths, and at the same time obtain the specific device models involved on the paths; Equipment specification retrieval: Based on the specific equipment model determined by physical status retrieval and the technical path determined by macro-architecture retrieval, the corresponding configuration manual summary and command template are retrieved in the knowledge concept layer graph to obtain the correct command syntax and parameters.

10. A network control intent translation method based on GraphRAG as described in any one of claims 1 to 9, characterized in that, Step 4 specifically includes the following steps: Step 4.1: Serialize the final context subgraph obtained in Step 3 into an LLM-readable text format and combine it with the user's original intent to form an enhanced prompt. Step 4.2: Input the prompt generated in Step 4.1 into the LLM, and through the corresponding prompt word template, instruct it to generate a network configuration policy that meets the intent requirements and conforms to the current network status. Step 4.3: Distribute the generated policy to network devices for execution, monitor the changes in network status after execution, and feed the changes back to the knowledge graph in Step 1 to form an automated closed loop.

Images