Multi-agent automatic base station site selection method and system based on large language model driving

Abstract

The invention relates to a multi-agent automatic base station site selection method and system based on large language model driving, and the method comprises the steps: 1, problem modeling: understanding the background and demands of a problem, and carrying out the automatic modeling of a mathematical optimization model; 2, code generation: selecting a proper optimization algorithm according to the mathematical optimization model, automatically compiling a corresponding executable code, and feeding and correcting the executable code; step 3, code execution: executing the generated optimization code, and collecting and sorting a site selection scheme output by the code; 4, result evaluation: according to problem requirements and constraint conditions in a mathematical optimization model, carrying out validity verification on the site selection scheme output in the step 3; step 5, repeatedly executing until a feasible site selection scheme is output; step 6, online self-healing re-planning: monitoring the network KPI in real time; according to the method, the efficiency and the automation level are remarkably improved, the site selection period of the base station is shortened, and the dependence on artificial experts is reduced.

Description

TECHNICAL FIELD

[0001] The application relates to a multi-agent automatic base station site selection method and system based on a large language model driver, and belongs to the technical field of communication network optimization. BACKGROUND

[0002] As the backbone of mobile communication networks, base stations not only provide seamless connectivity for mobile users, ensuring the continuity and reliability of communication, but also support the growing demand for high data throughput, allowing users to enjoy high-speed network services even when they are on the move [Cui W, Zhang Y, Wei L, et al. Optimizing base stations deployment in wireless access networks for smart grids [C] / / 2015 International Conference on Wireless Communications & Signal Processing (WCSP). IEEE, 2015: 1-5.]. With the popularity of smartphones and mobile devices, the number of mobile users has surged, and users' demand for data transmission speed and quality has correspondingly increased. Therefore, the base station site selection problem is particularly critical and challenging, as it directly affects the breadth and depth of network coverage and the quality of user service experience.

[0003] Conventional base station siting methods mainly rely on road tests and user feedback to assess network performance and identify areas that need improvement, and use this as a standard to determine the type and location of new base stations. There are two problems: (1) Road tests collect signal quality data by deploying measurement equipment in a specific geographic area, although this method can provide valuable insights, it is time-consuming and impractical, especially in densely populated urban environments [Tayal S, Garg P K, Vijay S. Optimization models for selecting base station sites for cellular network planning [C] / / Applications of Geomatics in Civil Engineering: Select Proceedings of ICGCE 2018. Springer Singapore, 2020: 637-647.]. In addition, road tests only capture data at a specific time and place, and cannot fully reflect the dynamic changes in network performance over time; (2) User complaints and feedback are another means of identifying coverage problems and quality of service defects in traditional methods. However, this reactive strategy means that network improvements are usually initiated when problems are serious enough to trigger user complaints [Kulin M, Kazaz T, De Poorter E, et al. A survey on machine learning-based performance improvement of wireless networks: PHY, MAC and network layer [J]. Electronics, 2021, 10(3): 318.]. In addition, the feedback collected may not represent the entire user base, resulting in biased or incomplete data. Engineers need to analyze this feedback, model the base station siting problem, develop solutions, deploy new base stations, and re-evaluate network performance, forming a continuous and iterative process.

[0004] In summary, traditional methods are not only time-consuming, but also require engineers to have extensive expertise in communications, networks, and optimization, resulting in a long cycle and significant manpower costs to solve the base station siting problem. SUMMARY

[0005] To solve the above technical problems, the present application proposes a multi-agent automated base station site selection method and system based on large language model driving. This method aims to automatically complete the complex process of base station site selection by simulating the collaboration mode of human expert teams. Specifically, the present application constructs a collaborative framework composed of multiple specialized agents. Among them, the problem modeling agent is responsible for receiving the initial requirements of base station site selection, understanding the problem background, and automatically modeling it into a precise mathematical optimization model. Subsequently, the code generation agent selects the appropriate optimization algorithm according to the mathematical model, automatically writes the corresponding executable code, and can correct the code according to subsequent feedback. Then, the optimization execution agent is responsible for executing the generated optimization code and collecting and organizing the code running results. Finally, the result testing agent verifies the effectiveness of the site selection scheme output by the optimization execution agent according to the original problem requirements and the constraints in the mathematical model, and the test results can be fed back to the code generation agent for further correction of the code. Further, in the network running stage, the online self-healing re-planning agent realizes the dynamic adjustment of network parameters based on real-time key performance indicators (KPIs) to continuously maintain the optimality of the site selection scheme. In particular, to improve the accuracy and reliability of the generated content of each agent and reduce the inherent "hallucination" phenomenon of large language models, the present application introduces the Retrieval-Augmented Generation (RAG) technology. By combining external knowledge bases (such as engineering specifications, algorithm libraries, geographic information data, etc.), each agent can retrieve relevant reliable information before executing the task and integrate it into the generation process, thereby significantly improving the accuracy of mathematical modeling, the correctness of code, and the effectiveness of result verification. The multi-agent system interacts through a pre-set collaborative workflow, forming a closed-loop iterative optimization process.

[0006] Terminology explanation:

[0007] 1. Genetic algorithm: a meta-heuristic optimization algorithm based on simulating the process of biological evolution. It maintains a population of potential solutions and applies genetic operators such as selection, crossover, and mutation to iteratively evolve the quality of solutions to search for optimal or near-optimal solutions.

[0008] 2. Particle swarm optimization: an optimization algorithm derived from swarm intelligence, simulating social behaviors such as bird foraging. Each "particle" in the algorithm represents a potential solution, moving and searching in the solution space based on its own historical optimal position and the global optimal position of the entire group.

[0009] 3. Simulated Annealing: A probabilistic metaheuristic optimization algorithm inspired by the annealing process of solid materials. The algorithm introduces a control parameter (similar to "temperature") to allow accepting inferior solutions with a certain probability at the early stage of search, providing the opportunity to escape from local optima. As the "temperature" gradually decreases, the probability of accepting inferior solutions decreases, and the algorithm eventually converges to a high-quality solution.

[0010] 4. Linear Programming: A mathematical optimization method specifically designed for solving optimization problems where both the objective function and the constraints are linear. It aims to find the values of decision variables that maximize or minimize a linear objective function subject to a set of linear equalities or inequalities.

[0011] 5. Online Self-healing Phase: Under the condition that the base station has been put into operation, through the minimization of difference demand and code patch technology, the network parameter re-optimization process is realized with second-level hot update without interrupting the service.

[0012] 6. Diff-Prompt Submodule: The key functional module of the code generation agent in the online self-healing scenario, mainly used for minimal modification of existing and verified executable optimization code to ensure that the network parameter or site selection scheme can be quickly adjusted in a dynamic environment without damaging the overall structure.

[0013] The technical solution of the present application is:

[0014] A multi-agent automatic base station site selection method based on large language model driving, comprising:

[0015] Step 1: Problem modeling: understand the problem background and requirements, and automatically model into a mathematical optimization model;

[0016] Step 2: Code generation: select appropriate optimization algorithm according to the mathematical optimization model, automatically write corresponding executable code, and modify the executable code according to subsequent feedback;

[0017] Step 3: Code execution: execute the optimization code generated in step 2, and collect and arrange the site selection scheme output by the code;

[0018] Step 4: Result evaluation: according to the problem requirements and the constraint conditions in the mathematical optimization model, the site selection scheme output in step 3 is verified for effectiveness, and the verification result is fed back to step 2 for further optimization of the code;

[0019] Step 5: Repeat steps 2 to 4 until a feasible site selection scheme is output;

[0020] Step 6: Online self-healing re-planning: real-time monitoring of network KPIs; if the KPIs deviate from the preset threshold, the online self-healing re-planning agent extracts the local difference demand ΔD; calls the Diff-Prompt sub-module in the code generation agent to perform a minimum patch on the previously verified executable code; the optimization execution agent performs A / B verification on the patch through its gray verification sub-module; after verification, it is deployed through a hot update mechanism with zero downtime, and step 6 is continuously cycled.

[0021] According to the present application, preferably, in step 1, the specific operation steps of problem modeling include:

[0022] Step 1.1: Receive and parse user input information: obtain user-provided base station site selection related data, including: geographic coordinates of existing base stations; geographic coordinates and estimated traffic of weak coverage areas; technical parameters of candidate base station types; and user-specified constraint conditions and optimization target settings;

[0023] Step 1.2: Retrieve information using retrieval enhancement generation technology: query associated external knowledge bases to obtain background information and modeling reference materials related to the current task;

[0024] Step 1.3: Identify and define model elements based on user input information and technical retrieval information: combine the user input information of step 1.1 and the technical retrieval information generated in step 1.2 to identify and clearly define the objective function and constraint conditions of the optimization problem;

[0025] Step 1.4: Formalize the model using mathematical language: express the determined objective function and all constraint conditions in a standardized mathematical language to generate a mathematical optimization model including mathematical formulas, parameter definitions, and decision variable definitions, as follows:

[0026]

[0027] wherein,

[0028]

[0029] In formulas (I) and (II), i represents the i-th existing base station; h represents a macro base station, C h represents the cost of a macro base station, d h represents the coverage range of a macro base station; x n represents the horizontal coordinate of the n-th candidate base station; y n represents the vertical coordinate of the n-th candidate base station; P i,h,t and P i,d,t respectively represent a device located at position t ∈ G i i i ​​Probability of being covered by a macro or micro base station of the network; G i represents the entire area in grid i; w t represents the traffic volume associated with the location (x t ,y t ); represents the set of coordinates of all candidate new base station locations; N represents the total number of grid points; represents the set of coordinates of all existing base stations; d h and d d represent the coverage radius of macro and micro base stations, respectively; C h and C d represent the cost of macro and micro base stations, respectively; D min represents the minimum distance between any two base stations; p i and q i represent the Boolean variables of whether to deploy a macro or micro base station at the center point of grid i; (x i ,y i ) is the coordinate of the center point of grid i; is the coordinate of existing base station j.

[0030] According to the present application, in step 2, the specific operation steps of code generation include:

[0031] Step 2.1: Analyze the characteristics of the mathematical optimization model: receive and parse the mathematical optimization model, analyze the key characteristics of the mathematical optimization model, including the type of objective function, the nature of the constraint condition, and the type of decision variable;

[0032] Step 2.2: Retrieve algorithm and implementation information using the Retrieval Augmented Generation (RAG) technique: as shown in Figure 3 ;

[0033] Retrieve optimization algorithms and their engineering implementation cases that match the current mathematical optimization model in the external knowledge base through the RAG technique; the recall content includes numerical optimization libraries and meta-heuristic algorithms; in the recall results, sort according to the credibility score; after sorting, select the top-scoring algorithm set to form the optimal candidate algorithm set as a reference for subsequent code generation;

[0034] If the mathematical optimization model is controllable in size, i.e., the number of problem variables and constraint conditions are within the range that can be handled by a conventional numerical solver, and has a good linear structure, then the numerical optimization library is called first;

[0035] If the mathematical optimization model contains complex nonlinearity or involves terrain fading modeling, then a hybrid strategy of coarse-grained meta-heuristic and local MILP refinement is adopted; the specific process is as follows:

[0036] Coarse-grained meta-heuristic search: quickly search a set of approximate feasible solutions in a large solution space;

[0037] Local MILP refinement: take these approximate feasible solutions as input, call the mixed integer linear programming solver to fine-tune and correct constraints in a local range, so as to obtain a solution closer to the global optimum, that is, the optimal candidate algorithm set;

[0038] Step 2.3: Generate initial executable optimization code: based on the optimal candidate algorithm set screened in step 2.2, generate an initial solving script;

[0039] The initial solving script automatically inserts logging and indicator reporting logic, and synchronously generates a configuration file and a CI unit test case;

[0040] Step 2.4: Receive execution feedback and iteratively modify the code: during the execution of the initial solving script, if syntax errors, dependency conflicts, solution divergence or constraint violations occur, error logs and execution contexts will be automatically collected, and existing abstract syntax tree parsing and exception stack tracking technologies will be used for root cause localization; then, the RAG technology is used to retrieve error repair patterns and alternative implementation fragments to generate a difference patch;

[0041] Step 2.5: Diff-Prompt sub-module operation: input original script S, difference requirement ΔD and the latest execution log;

[0042] In terms of modification strategy, parameter updating is preferred, and then local operator replacement is considered; the output results include the patched script, the corresponding difference file, the change summary, the list of affected functions / classes and the rollback script;

[0043] According to the present application, preferably, in step 3, the specific operation steps of code execution include:

[0044] Step 3.1: Receive and prepare the execution environment: the optimization execution agent receives the latest version of the executable optimization code generated after the iterative modification in step 2.4, and prepares the required environment for running; including loading input data and installing dependent libraries;

[0045] If this execution belongs to the online self-healing stage, the gray verification submodule is triggered to initialize;

[0046] Step 3.2: Attempt to execute the optimization code: start and run the optimization solving process defined in the executable optimization code;

[0047] If it is in the online self-healing stage, the gray verification submodule runs the original version + patch version dual instances in parallel in the same sandbox;

[0048] Step 3.3: Monitor execution process and handle runtime exceptions: During the code execution, monitor its running state; if an instant error is encountered during the execution start or process, capture detailed error information;

[0049] If in the gray-scale verification mode, the gray-scale verification submodule compares the KPI difference between the patch version and the original version; the judgment logic is: if the patch version has significant improvement in the KPI in the difference requirement ΔD region, and at the same time all the hard constraints are not violated, it is marked as "verification passed"; significant improvement refers to the reduction of call drop rate or the improvement of throughput; otherwise, it is marked as "verification failed", and a rollback operation is triggered;

[0050] Step 3.4: Capture optimization solver state and results: If the code is successfully started and the optimization solver is run, monitor the solving process until it terminates; capture the final state information of the optimization solver and the original optimization results output by the code;

[0051] If the verification is passed, the gray-scale verification submodule packages the patch version code, the running results and the KPI difference analysis into a "hot update package"; if the verification fails, a rollback instruction is generated and the recovery to the last stable version is notified;

[0052] Step 3.5: Structured packaging and transmission of execution information: The captured execution results are arranged and packaged into structured data;

[0053] If an instant error occurs in step 3.3, detailed error information is fed back to step 2 to trigger code correction;

[0054] If the code execution is completed, the data containing the original results and the gray-scale verification conclusion are transmitted to step 4 for further evaluation, or directly enter the hot update process in the self-healing scene.

[0055] According to the present application, preferably, in step 4, the specific operation steps of result evaluation include:

[0056] Step 4.1: Receive execution results and original constraints: receive the structured data transmitted from step 3, and at the same time, obtain the problem requirements and the constraint conditions of the formalized mathematical optimization model defined in step 1;

[0057] Step 4.2: Constraint compliance verification of optimization results: when the solver reports a potential solution, i.e. a candidate base station site selection scheme returned by the solver in step 3, according to the constraint conditions of the mathematical optimization model obtained in step 4.1, systematically verify whether the potential solution satisfies all the hard constraints;

[0058] Step 4.3: Determine the feasibility of the scheme and generate feedback:

[0059] If all constraints are satisfied based on the verification of step 4.2, it is determined that the site selection scheme is a feasible scheme, and the site selection scheme is the solution vector output in step 3, that is, a complete deployment scheme composed of specific new station positions and types;

[0060] If at least one constraint is not satisfied, it is determined that the scheme is not feasible, and all specific constraints that are violated and the violation degrees thereof are identified;

[0061] Step 4.4: Transmit the verification result and feedback information:

[0062] If the scheme is feasible and a preset stopping condition is satisfied, the feasible solution is output as a final result;

[0063] If the scheme is not feasible or the solver fails, detailed verification result feedback is provided to the code generation agent for guiding code modification or possible algorithm / parameter adjustment in the next round.

[0064] According to the present application, preferably, in step 6, the specific operation steps of the online self-recovery re-planning include:

[0065] Step 6.1: KPI acquisition: real-time acquisition of cell-level key performance indicators KPIs;

[0066] Step 6.2: Difference demand generation: after the acquisition of the cell-level key performance indicators KPIs, the mean and variance of each indicator KPI are calculated by a sliding window statistical method, and abnormal fluctuations are identified in combination with historical distribution characteristics and an anomaly detection algorithm;

[0067] Step 6.3: Call the Diff-Prompt sub-module: after the difference demand ΔD is generated, the Diff-Prompt sub-module is triggered to perform minimal modification on the original script S;

[0068] Step 6.4: Gray verification: the A / B comparison of S and S' is performed by the optimization execution agent in the twin sandbox, and if the KPIs are improved and no constraint violation occurs, it is marked as passed, otherwise, it is determined as failed;

[0069] Step 6.5: Hot update deployment: the patch is hot-loaded to the live network through the CI / CD pipeline to realize second-level switching;

[0070] Step 6.6: Rollback mechanism: if the gray verification fails or the KPIs deteriorate after the patch is put into operation, automatic rollback is performed to restore to the last stable version, and an alarm is generated and a work order is recorded.

[0071] A multi-agent automatic base station site selection system driven by a large language model, comprising:

[0072] The problem modeling module is configured to understand the problem background and requirements and automatically model them into a mathematical optimization model;

[0073] The code generation module is configured to select a suitable optimization algorithm according to the mathematical optimization model, automatically write corresponding executable code, and correct the executable code according to subsequent feedback;

[0074] The code execution module is configured to execute the generated optimization code and collect and arrange the site selection scheme output by the code;

[0075] The result evaluation module is configured to verify the effectiveness of the output site selection scheme according to the problem requirements and the constraint conditions in the mathematical optimization model, and feed back the verification results for guiding further optimization of the code;

[0076] The online self-healing re-planning module is configured to monitor the network KPI in real time; if the KPI deviates from the preset threshold, the online self-healing re-planning agent extracts the local difference requirement ΔD; calls the Diff-Prompt sub-module in the code generation agent to perform the minimum patch on the previously verified executable code; the optimization execution agent performs A / B verification on the patch through its gray verification sub-module; after verification, the patch is deployed through a hot update mechanism without stopping, and the online self-healing re-planning is continuously executed in a loop.

[0077] The beneficial effects of the present application are:

[0078] Through the multi-agent collaborative automatic processing of modeling, coding, execution, testing and other links, the efficiency and automation level are significantly improved, the base station site selection cycle is shortened, and the dependence on human experts is reduced. By utilizing the professional advantages of different agents and combining the capabilities of large language models (LLM), the solving ability for the complexity, multi-constraint and dynamics of the base station site selection problem is effectively enhanced. The introduction of retrieval-augmented generation (RAG) technology effectively alleviates the illusion problem of LLM, ensuring the accuracy and reliability of model construction, code generation and result verification, thereby improving the quality of the final site selection scheme. In addition, the system can quickly adjust the strategy based on updated demand or environmental data, showing strong adaptability and flexibility, and providing flexible and efficient solutions. Finally, the automated process greatly reduces the labor cost and human intervention, and reduces the potential human errors in project implementation. In summary, the present application provides an efficient, automatic, reliable and adaptable innovative solution for the base station site selection problem by constructing a multi-agent collaborative framework driven by LLM and enhanced by RAG. Further, through the online self-healing re-planning agent, the continuous optimization of the deployed base station is realized, without manual midnight switching, significantly improving the network availability and operation efficiency, and reducing the risk of human operation. BRIEF DESCRIPTION OF DRAWINGS

[0079] Figure 1 is a schematic diagram of base station site selection problem;

[0080] Figure 2 is a flowchart of multiple large models cooperating to solve the base station site selection problem;

[0081] Figure 3 is a search enhancement generation technique schematic diagram;

[0082] Figure 4 is a base station site selection map of the present application under the premise of meeting 90% traffic coverage. DETAILED DESCRIPTION

[0083] The present application will be further described below in conjunction with the accompanying drawings and examples, but is not limited thereto.

[0084] Example 1

[0085] A multi-agent automatic base station site selection method based on large language model driving, as shown in Figure 2 , comprising:

[0086] Step 1: Problem modeling: the problem modeling agent is responsible for understanding the problem background and requirements, and automatically modeling into a mathematical optimization model;

[0087] Step 2: Code generation: the code generation agent selects a suitable optimization algorithm according to the mathematical optimization model, automatically writes the corresponding executable code, and corrects the executable code according to the subsequent feedback;

[0088] Step 3: Code execution: the optimization execution agent is responsible for executing the optimization code generated in step 2, and collecting and arranging the site selection scheme output by the code;

[0089] Step 4: Result evaluation: the result test agent verifies the effectiveness of the site selection scheme output in step 3 according to the problem requirements and the constraint conditions in the mathematical optimization model, and the verification result is fed back to step 2 for further optimization of the code;

[0090] Step 5: Repeat steps 2 to 4 until a feasible site selection scheme is output;

[0091] Step 6: Online self-recovery re-planning: real-time monitoring of network KPI; if the KPI deviates from the preset threshold, the online self-recovery re-planning agent extracts the local difference requirement ΔD; calls the Diff-Prompt sub-module in the code generation agent to make a minimum patch to the previously verified executable code; the optimization execution agent performs A / B verification on the patch through its gray verification sub-module; after verification, it is deployed through a hot update mechanism without stopping, and step 6 is continuously cycled.

[0092] Example 2

[0093] According to the large language model driven multi-agent automatic base station site selection method described in embodiment 1, the difference lies in that:

[0094] In step 1, the specific operation steps of problem modeling include:

[0095] Step 1.1: Receive and analyze user input information: obtain user-provided base station site selection related data, including but not limited to: geographic coordinates of existing base stations; geographic coordinates and estimated traffic volume (i.e. total data traffic generated in the region during busy hours) of weak coverage areas (i.e. areas with weak signal); technical parameters (including coverage radius, cost, etc.) of candidate base station types (such as macro base stations and micro base stations); and user-specified constraints (such as minimum distance requirements between base stations, expressed in specific numerical values or grid units) and optimization goal settings; such as Figure 1 As shown.

[0096] The present application adopts the data set of problem D of the 2022 Mathematical Cup University Student Mathematical Modeling Challenge [“Mathorcup undergraduate mathematical modeling challenge 2022,” http: / / www.mathorcup.org.], which includes a 2500x2500 grid area, and the coordinate range of each grid point is 0 to 2499. The data set provides the coordinates of weak coverage points and the corresponding traffic volume, as well as the coordinate data of the built base stations. The data set also defines two types of base stations: macro base stations with a coverage range of 30 grids and a cost of 10, and micro base stations with a coverage range of 10 grids and a cost of 1.

[0097] Step 1.2: Use Retrieval-Augmented Generation (RAG) technology to retrieve information: query the associated external knowledge base, which includes telecommunications network planning specifications, base station site selection model examples, historical cases, etc. Obtain background information and modeling reference materials related to the current task;

[0098] Step 1.3: Identify and define model elements based on user input information and technical retrieval information: combine the user input information of step 1.1 and the technical retrieval information generated in step 1.2 to identify and clearly define the objective function and constraints of the optimization problem; for example, determine the objective function as the minimization of total cost under the condition of meeting a certain traffic coverage rate (such as not less than 90%), and determine the constraint condition as the distance between new base stations and between new and old base stations must be greater than a set threshold.

[0099] Step 1.4: Formalize the model using mathematical language: Express the determined objective function and all constraints in a standardized mathematical language (such as LaTeX syntax) to generate a mathematical optimization model that includes mathematical formulas, parameter definitions (such as cost coefficients, coverage radius, distance threshold), and decision variable definitions (such as variables indicating the location and type of base station construction), as follows:

[0100]

[0101] where,

[0102]

[0103] In formulas (I) and (II), i represents the i-th existing base station; h h represents the cost of a macro base station, d h represents the coverage range of a macro base station; x n represents the horizontal coordinate of the n-th candidate base station; y n represents the vertical coordinate of the n-th candidate base station; P i,h,t and P i,d,t respectively represent the probability that a device located at position t ∈ G i (coordinates (x t , y t )) is covered by a macro base station or a micro base station located at (x i , y i ); G i represents the entire area in grid i; w t represents the traffic volume associated with position (x t , y t ); represents the coordinate set of all candidate new base station locations; N represents the total number of grid points; represents the coordinate set of all existing base stations; d h and d d represent the coverage radius of macro base stations and micro base stations, respectively; C h and C d represent the cost of macro base stations and micro base stations, respectively; D min represents the minimum distance between any two base stations; p i and q i are Boolean variables indicating whether a macro base station or a micro base station is deployed at the center point of grid i; (x i , y i ) is the coordinate of the center point of grid i; is the coordinate of the existing base station j.

[0104] In step 2, the specific operation steps of code generation include:

[0105] Step 2.1: Analyze the mathematical optimization model's characteristics: receive and parse the mathematical optimization model, analyze its key characteristics, including the type of objective function (linear, nonlinear, or multi-objective form), the nature of the constraints (linear equations / inequalities, nonlinear, or integer constraints), and the type of decision variables (continuous coordinates, integer quantities, or Boolean location flags);

[0106] Step 2.2: Retrieve algorithm and implementation information using Retrieval-Augmented Generation (RAG) technology:

[0107] Retrieve optimization algorithms and their engineering implementation cases (such as published planning models and optimization solving practice cases) that match the current mathematical optimization model in an external knowledge base through RAG technology; the recalled content includes numerical optimization libraries (such as OR-Tools, Gurobi, CPLEX, Pyomo, Pulp) and meta-heuristic algorithms (such as Genetic Algorithm GA, Particle Swarm Optimization PSO, Simulated Annealing SA, Tabu Search TS); in the recalled results, the system will be sorted according to the credibility score; the evaluation dimensions of the credibility score include: source authority (such as whether it comes from mature commercial solvers or academic authoritative publications); executability verification (whether the algorithm has a stable implementation that can be directly reused); case similarity (whether the algorithm has been verified in a similar problem structure to the current problem). After sorting, the top-scoring algorithms are selected to form the optimal candidate algorithm set, which serves as a reference for subsequent code generation;

[0108] If the mathematical optimization model is controllable in size, i.e., the number of problem variables and constraints is within the range that a conventional numerical solver can handle (e.g., the number of variables is within the thousands, and the number of constraints is within a few hundred, and the solver can complete convergence within minutes to hours), and has a good linear structure (i.e., the objective function and constraints are linear, and do not contain non-convex constraints or complex nonlinear relationships), then numerical optimization libraries (such as Gurobi, CPLEX) are preferred; to take advantage of their efficient and accurate solving capabilities for small-scale linear programming problems.

[0109] If the mathematical optimization model contains complex nonlinearities (such as exponential decay relationship between coverage probability and distance, or user distribution unevenness) or involves terrain fading modeling (e.g., in mountainous or high-rise urban environments, considering shadow fading, path loss, and multi-path effect nonlinear propagation characteristics), then a hybrid strategy of coarse-grained meta-heuristic and local MILP refinement is adopted; the specific process is as follows:

[0110] Coarse-grained meta-heuristic search: use meta-heuristic methods such as genetic algorithms and particle swarm optimization to quickly search for a set of approximate feasible solutions in a large solution space;

[0111] Local MILP Refinement: Take these approximate feasible solutions as input, call the mixed integer linear programming (MILP) solver to fine-tune the optimization and constraint correction in a local range, so as to obtain a solution closer to the global optimum, i.e. the optimal candidate algorithm set;

[0112] Step 2.3: Generate initial executable optimization code: based on the optimal candidate algorithm set screened in step 2.2, generate an initial solving script; the initial solving script includes data loading, model construction, solving and result storage, etc. basic functions, where the results can be saved in existing common data formats (such as CSV, JSON) for subsequent analysis. The above modules are existing implementation methods and can be directly reused in engineering.

[0113] The initial solving script automatically inserts log recording and index reporting logic, and synchronously generates configuration files (YAML / JSON format) and CI unit test cases; to support subsequent automated execution and regression verification.

[0114] Step 2.4: Receive execution feedback and iteratively modify the code: during the execution of the initial solving script, if syntax errors, dependency conflicts, non-convergent solving or constraint violations occur, error logs and execution context will be automatically collected, and existing abstract syntax tree (AST) parsing and exception stack tracking techniques will be used for root cause analysis; then, through RAG technology, retrieve error repair patterns and alternative implementation fragments to generate a difference patch (git-diff syntax); only the relevant functions or classes are modified locally to avoid global structure damage. The modified script is automatically subjected to unit / integration testing and returns the optimized execution agent and result test agent verification.

[0115] Step 2.5: Diff-Prompt sub-module operation (for online self-healing scenarios): input original script S, difference requirement ΔD (including exception area index, affected KPI, and allowed parameter / constraint range) and recent execution logs; this sub-module specifies which content cannot be modified through a structured prompt template, such as hard constraints in mathematical optimization models (budget upper limit, coverage lower limit, capacity constraint, minimum distance constraint); the range allowed to adjust is limited to the following categories: mathematical optimization model weight, candidate site filtering condition, transmit power upper and lower bound, penalty term coefficient, iteration number, convergence threshold and neighborhood search radius.

[0116] In terms of modification strategy, parameter updating (such as adjusting the power upper limit of a certain area or the weight of the optimization target) is given priority, followed by local operator replacement (such as replacing the search neighborhood or heuristic operator); the output results include the patched script, the corresponding difference file (git-diff format), the change summary, the list of affected functions / classes and the rollback script; so as to ensure that the modification process is both controllable and reversible.

[0117] For example, if the drop call rate in a certain city suddenly increases, ΔD will mark the KPI anomaly of the region and allow adjustments within the "power boundary" and "penalty term weight" range. The Diff-Prompt sub-module generates a patch accordingly, which only moderately reduces the upper limit of power and increases the weight of the drop call rate constraint. After the modification is completed, the system generates a patch file and a rollback script, and judges whether the new script is effective through gray-scale verification. If the improvement is obvious, it will be put online, otherwise it will be immediately rolled back.

[0118] In step 3, the specific operation steps of the code execution include:

[0119] Step 3.1: Receive and prepare the execution environment: the optimization execution agent receives the latest version of the executable optimization code (such as Python script) generated after the iterative modification in step 2.4, and prepares the environment required for running; including loading input data (such as candidate site coordinates, user distribution, existing base station information) and installing dependent libraries; ensure that the code can be executed smoothly in a complete and correct environment.

[0120] If this execution belongs to the online self-healing stage, the gray-scale verification submodule is triggered; the gray-scale verification submodule is an internal component of the agent, which is used for safety verification of the patch code. It will first clone the production twin sandbox environment (i.e. an isolated running environment consistent with the live network), and only import the local data slice related to the difference demand ΔD, such as the user distribution, topology and KPI data of the abnormal area, in order to reduce resource occupation and ensure that the verification process is isolated from the live network logic.

[0121] Step 3.2: Try to execute the optimization code: start and run the optimization solving process defined in the executable optimization code;

[0122] If it is in the online self-healing stage, the gray-scale verification submodule runs the original version + patch version double instances in the same sandbox; "original version" refers to the script S stably running in the live network, and "patch version" refers to the revised script S' generated by Diff-Prompt. The KPIs of both sides refer to the performance indicators obtained after running the two codes, such as coverage, drop call rate, call success rate, PRB utilization, uplink and downlink throughput, and handover success rate. These KPIs are collected by the system after running with the same input data, so that the difference is only caused by code modification.

[0123] Step 3.3: Monitor the execution process and handle runtime exceptions: monitor the running state during code execution; if an immediate error is encountered during execution startup or process, such as code syntax error, missing dependency, file read / write failure or uncaught runtime exception causing program crash, capture detailed error information (including error type, location and stack trace);

[0124] If in the gray-scale verification mode, the gray-scale verification submodule compares the KPI difference between the patch version and the original version; the judgment logic is: if the patch version has significant improvement in the KPI in the difference requirement ΔD region, and at the same time all the hard constraints (such as budget, coverage, capacity and minimum distance requirement) are not violated, it is marked as “verification passed”; significant improvement refers to the drop call rate reduction or throughput improvement; otherwise, it is marked as “verification failed”, and a rollback operation is triggered;

[0125] Step 3.4: Capture the optimization solver state and results: if the code is successfully started and runs the optimization solver, monitor the solving process until it terminates; capture the final state information of the optimization solver (such as reaching the time / iteration limit, solver internal error) and the original optimization results output by the code (such as the calculated new base station coordinates, type, objective function value, etc.);

[0126] If “verification passed” (i.e. the gray-scale comparison judgment in step 3.3 confirms that the patch code significantly improves the KPI in the affected area and no constraints are violated), the gray-scale verification submodule packages the patch version code, running results and KPI difference analysis into a “hot update package”; if the verification fails, a rollback instruction is generated and the recovery to the last stable version is notified;

[0127] Step 3.5: Structured packaging and transmission of execution information: organize and package the captured execution results (including original optimization results, possible runtime error information, judgment conclusion of the gray-scale verification submodule) into structured data;

[0128] If the immediacy error in step 3.3 occurs, detailed error information is fed back to step 2 to trigger code correction;

[0129] If the code execution is completed, the data containing the original results and the gray-scale verification conclusion are transmitted to step 4 for further evaluation, or directly enter the hot update process in the self-healing scenario.

[0130] In step 4, the specific operation steps of result evaluation include:

[0131] Step 4.1: Receive execution results and original constraints: receive the structured data (including original optimization results and solver final state) transmitted from step 3, and at the same time, obtain the problem requirements defined in step 1 and the constraint conditions of the formalized mathematical optimization model;

[0132] Step 4.2: Constraint compliance verification on optimization results: When the solver reports that a potential solution is found, i.e. a candidate base station site selection scheme returned by the solver in Step 3, no matter whether it is the optimal solution or suboptimal solution, it enters the verification stage as long as the basic feasibility condition is met. On this basis, the system verifies whether the potential solution satisfies all the hard constraints according to the constraint conditions of the mathematical optimization model obtained in Step 4.1; for example, the distances between new base stations in the scheme, the distances between new and old base stations are calculated and compared with the minimum distance constraint; the total cost of the scheme is calculated and compared with the budget constraint (if any); whether the scheme meets the minimum traffic coverage requirement (e.g. 90%) is evaluated;

[0133] Step 4.3: Determine the feasibility of the scheme and generate feedback:

[0134] If all the constraints are satisfied based on the verification in Step 4.2, it is determined that the site selection scheme is a feasible scheme, and the site selection scheme is the solution vector output in Step 3, i.e. a complete deployment scheme consisting of specific new site locations and types;

[0135] If at least one constraint is not satisfied, it is determined that the scheme is not feasible, and all the specific constraints that are violated and the degree of violation (e.g. how much the distance is insufficient, how much the coverage rate is insufficient) are identified;

[0136] Step 4.4: Deliver verification results and feedback information:

[0137] If the scheme is feasible and meets the preset stopping condition (e.g. reaches the target optimization level or the number of iterations), the feasible solution is output as the final result;

[0138] If the scheme is not feasible or the solver fails, the detailed verification results (indicating which constraints are violated and the degree of violation) are fed back to the code generation agent (Step 4.2) for guidance in the next round of code modification or possible algorithm / parameter adjustment.

[0139] In Step 6, the specific operation steps of online self-healing re-planning include:

[0140] Step 6.1: KPI collection: Real-time acquisition of cell-level key performance indicators KPIs from network management systems (OMC / EMS), performance management systems (PM) or passive measurements of probes / APPs through the northbound interface of the operator; including: call drop rate, call connection rate, RRC establishment success rate, ERAB establishment success rate, PRB / PUCCH / PUSCH / PRACH utilization rate, uplink and downlink throughput, handover success rate and handover failure rate, RSRP / RSRQ / SINR distribution, TA distribution, weak coverage ratio, overlapping coverage ratio, alarm rate and TOPN abnormal cells, etc. Data are usually periodically pulled with a granularity of 5 minutes or 15 minutes, or can be acquired in real time in a streaming manner, so as to ensure the real-time and completeness of monitoring.

[0141] Step 6.2: Difference demand generation: After collecting key performance indicators (KPIs) at the cell level, the mean and variance of each KPI are calculated using a sliding window statistical method. In combination with historical distribution characteristics and anomaly detection algorithms (such as STL decomposition and ESD anomaly detection), abnormal fluctuations are identified. If a KPI exceeds the preset threshold vector τ, the cell or region is marked as abnormal, and a difference demand ΔD is automatically generated. ΔD includes the affected area index, abnormal indicators, constraints that need to be maintained, and adjustable parameter ranges. The threshold range is determined based on SLA or historical distribution. For example, the connection rate requirement is greater than 95%, the call drop rate is less than 2%, and the PRB utilization rate is not higher than 90%, and it can be adjusted adaptively according to the business period.

[0142] Step 6.3: Call Diff-Prompt submodule: When the difference demand ΔD is generated, trigger the Diff-Prompt submodule to make minimal modifications to the original script S. The specific process is to take S, ΔD, and the latest execution log as input, and combine the structured prompt template to explicitly indicate that hard constraints cannot be modified. The allowed modifications are limited to parameter updates or operator replacements, avoiding large-scale reconstruction. Finally, output the patch script S' and the corresponding git-diff file, and generate a change summary, a list of affected functions / classes, and a rollback script to ensure minimal and reversible modifications.

[0143] Step 6.4: Gray verification: The optimization execution agent performs A / B comparison of S and S' in the twin sandbox. If the KPIs improve and there is no constraint violation, it is marked as passed, otherwise it is determined as failed. A refers to the original script S, and B refers to the patched script S'. The original script S and the patched script S' are run in parallel under the same input and the same random seed. Only the data involved in ΔD is loaded in the sandbox, and the corresponding KPIs are collected after running. If the KPIs of the patched version in the abnormal area are significantly improved, such as call drop rate reduction and throughput rate increase, and all hard constraints (budget, coverage lower limit, capacity upper limit) are not violated, and other KPIs in the network do not appear to be deteriorated beyond the tolerance, then the gray verification is passed. Otherwise, it is determined as failed.

[0144] Step 6.5: Hot update deployment: The patch is hot-loaded to the live network through the CI / CD pipeline, achieving second-level switching. When the gray verification is passed, the patch S' is deployed in the live network through the CI / CD pipeline in a hot loading manner. The entire process includes static scanning, unit testing, integration testing, and approval gateway to ensure reliability. The system uses blue-green or canary release strategies to achieve second-level switching and phased online, reducing risks.

[0145] Step 6.6: Rollback mechanism: If the grayscale verification fails or the KPI deteriorates after the patch is put online, an automatic rollback is immediately performed to restore the previous stable version, and an alarm is generated and a work order is recorded. Ensure that the exception can be traced and avoid continuous expansion of the impact.

[0146] To evaluate the performance of the proposed scheme, the present application uses two main indicators: traffic coverage and cost. Traffic coverage is calculated as the percentage of weak coverage points covered by the base station in the total traffic, and the cost is measured by the total cost of the base stations used to achieve the expected traffic coverage. Figure 4 is the base station site selection map of the present application under the premise of meeting 90% traffic coverage. For the sake of problem simplicity, the present application uses a 100x100 grid area in the dataset, with a coordinate range of (300-399, 0-99), and sets the minimum traffic coverage ratio to 90% and minimizes the construction cost.

[0147] Embodiment 3

[0148] A multi-agent automatic base station site selection system driven by a large language model, comprising:

[0149] A problem modeling module configured to understand the problem background and requirements and automatically model them into a mathematical optimization model;

[0150] A code generation module configured to select a suitable optimization algorithm according to the mathematical optimization model, automatically write corresponding executable code, and correct the executable code according to subsequent feedback;

[0151] A code execution module configured to execute the generated optimization code and collect and organize the site selection scheme output by the code;

[0152] A result evaluation module configured to verify the effectiveness of the output site selection scheme according to the problem requirements and the constraint conditions in the mathematical optimization model, and feed back the verification results for further optimization of the code;

[0153] An online self-healing re-planning module configured to monitor network KPI in real time; if the KPI deviates from the preset threshold, the online self-healing re-planning agent extracts the local difference requirement ΔD; calls the Diff-Prompt sub-module in the code generation agent to make a minimum patch to the previously verified executable code; the optimization execution agent performs A / B verification on the patch through its grayscale verification sub-module; after verification, it is deployed through a hot update mechanism without downtime, and the online self-healing re-planning is continuously executed in a loop.

Claims

1. A multi-agent automated base station siting method based on a large language model driver, characterized in that, Comprises: Step 1: problem modeling: understand the problem background and requirements, and automatically model into a mathematical optimization model; Step 2: code generation: select the appropriate optimization algorithm according to the mathematical optimization model, automatically write the corresponding executable code, and modify the executable code according to the subsequent feedback; Step 3: code execution: execute the optimization code generated in step 2, and collect and arrange the site selection scheme output by the code; Step 4: result evaluation: according to the problem requirements and the constraint conditions in the mathematical optimization model, verify the effectiveness of the site selection scheme output in step 3, and feed back the verification results to step 2 for further optimization of the code; Step 5: repeat steps 2 to 4 until a feasible site selection scheme is output; Step 6: online self-recovery re-planning: real-time monitoring of network KPI; If the KPI deviates from the preset threshold, the online self-recovery re-planning agent extracts the local difference demand ΔD; calls the Diff-Prompt sub-module in the code generation agent to perform the minimum patch on the previously verified executable code; the optimization execution agent performs A / B verification on the patch through its gray verification sub-module; after verification, it is deployed through the hot update mechanism without stopping, and step 6 is continuously cycled.

2. The multi-agent automated base station siting method based on a large language model driver according to claim 1, characterized in that, In step 1, the specific operation steps of problem modeling include: Step 1.1: receive and parse user input information: obtain the user-provided base station site selection related data, including: geographic coordinates of existing base stations; geographic coordinates and estimated traffic of weak coverage areas; technical parameters of candidate base station types; and user-specified constraint conditions and optimization target settings; Step 1.2: retrieve information using retrieval enhancement generation technology: query the associated external knowledge base to obtain background information and modeling reference materials related to the current task; Step 1.3: identify and define model elements based on user input information and technical retrieval information: identify and clearly define the objective function and constraint conditions of the optimization problem based on the user input information in step 1.1 and the technical retrieval information generated in step 1.2; Step 1.4: formalize the model using mathematical language: formalize the determined objective function and all constraint conditions using standardized mathematical language to generate a mathematical optimization model including mathematical formulas, parameter definitions, and decision variable definitions, as shown below: Wherein, i represents the ith existing base station; h subscript represents macro base station, C h represents the cost of macro base station, d h represents the coverage of macro base station; x n represents the horizontal coordinate of the nth candidate base station; y n represents the vertical coordinate of the nth candidate base station; P i,h,t and P i,d,t respectively represent the probability that the device located at position t ∈ G i is covered by the macro base station or micro base station located at (x i , y i ); G i represents the entire area in grid i; w t represents the traffic volume related to the position (x t , y t ); represents the coordinate set of all candidate new base station positions; N represents the total number of grid points; represents the coordinate set of all existing base stations; d h and d d respectively represent the coverage radius of macro base station and micro base station; C h and C d respectively represent the cost of macro base station and micro base station; D min represents the minimum distance between any two base stations; p i and q i respectively represent the Boolean variable of whether to deploy macro base station or micro base station at the center point of grid i; (x i , y i ) is the coordinate of the center point of grid i; is the coordinate of the existing base station j.

3. The method of claim 1, wherein the method is based on a large language model driven multi-agent automatic base station site selection method. In step 2, the specific operation steps of code generation include: Step 2.1: analyze the characteristics of the mathematical optimization model: receive and parse the mathematical optimization model, analyze the key characteristics of the mathematical optimization model, including the type of objective function, the nature of constraint conditions, and the type of decision variables; Step 2.2: retrieve algorithm and implementation information using retrieval enhancement generation technology (RAG): Retrieve the optimization algorithm and its engineering implementation cases that match the current mathematical optimization model in the external knowledge base through RAG technology; the recalled content includes numerical optimization library and meta-heuristic algorithms; among the recalled results, sort according to the credibility score; after sorting, select the top scoring algorithm set as the reference basis for subsequent code generation; If the mathematical optimization model is controllable in size, i.e. the number of variables and constraints is within the scope of a conventional numerical solver, and has a good linear structure, the numerical optimization library is called first; If the mathematical optimization model contains complex nonlinearity or involves terrain fading modeling, a hybrid strategy of coarse-grained meta-heuristic and local MILP refinement is adopted; The specific process is as follows: Coarse-grained meta-heuristic search: quickly search a set of approximate feasible solutions in a large solution space; Local MILP refinement: take these approximate feasible solutions as input, call the mixed integer linear programming solver, and fine-tune and correct the constraints in a local range to obtain a solution closer to the global optimum, i.e. the optimal candidate algorithm set; Step 2.3: Generate initial executable optimization code: based on the optimal candidate algorithm set selected in step 2.2, generate the initial solving script; The initial solving script automatically inserts log recording and index reporting logic, and synchronously generates configuration files and CI unit test cases; Step 2.4: Receive execution feedback and iteratively modify the code: during the execution of the initial solving script, if syntax errors, dependency conflicts, non-convergent solutions, or constraint violations occur, error logs and execution contexts will be automatically collected, and existing abstract syntax tree parsing and exception stack tracking techniques will be used for root cause analysis; Then, the RAG technology is used to retrieve error repair patterns and alternative implementation fragments to generate a difference patch; Step 2.5: Diff-Prompt submodule operation: input original script S, difference requirement ΔD, and the latest execution log; In terms of modification strategy, parameter updating is preferred, followed by local operator replacement; The output results include the patched script, the corresponding difference file, the change summary, the list of affected functions / classes, and the rollback script.

4. The multi-agent automated base station siting method based on a large language model driver of claim 1, wherein, In step 3, the specific operation steps of code execution include: Step 3.1: Receive and prepare the execution environment: the optimization execution agent receives the latest version of the executable optimization code generated after the iterative modification in step 2.4, and prepares the required environment for running; This includes loading input data and installing dependent libraries; If this execution belongs to the online self-healing stage, the gray verification submodule is initialized; Step 3.2: Attempt to execute the optimization code: start and run the optimization solving process defined in the executable optimization code; If it is in the online self-healing stage, the gray verification submodule runs the original version and the patched version in parallel in the same sandbox; Step 3.3: Monitor the execution process and handle runtime exceptions: monitor the running state during code execution; If an immediate error is encountered during execution startup or process, capture detailed error information; If it is in the gray verification mode, the gray verification submodule compares the KPI differences between the patched version and the original version; The judgment logic is: if the KPI of the patched version in the difference requirement ΔD area is significantly improved, and at the same time all hard constraints are not violated, it is marked as "verification passed"; Significant improvement refers to the reduction of call drop rate or the increase of throughput; Otherwise, it is marked as "verification failed", and the rollback operation is triggered; Step 3.4: Capture the optimization solver state and results: If the code is successfully started and runs the optimization solver, monitor the solving process until it terminates; capture the final state information of the optimization solver and the original optimization results output by the code; If the verification passes, the gray verification submodule will package the patch version code, the running results, and the KPI difference analysis into a "hot update package"; if the verification fails, generate rollback instructions and notify the recovery to the last stable version; Step 3.5: Structured packaging and delivery of execution information: organize and package the captured execution results into structured data; If the instant error in step 3.3 occurs, detailed error information is fed back to step 2, triggering code correction; If the code execution is completed, the data containing the original results and the gray verification conclusion are transmitted to step 4 for further evaluation, or directly enter the hot update process in the self-healing scenario.

5. The multi-agent automated base station siting method based on a large language model driver of claim 1, wherein, In step 4, the specific operation steps of result evaluation include: Step 4.1: Receive execution results and original constraints: receive structured data from step 3, and at the same time, obtain the problem requirements and the constraint conditions of the formalized mathematical optimization model defined in step 1; Step 4.2: Constraint compliance verification of optimization results: when the solver reports a potential solution, i.e., a candidate base station site selection scheme returned by the solver in step 3, systematically verify whether the potential solution satisfies all hard constraints according to the constraint conditions of the mathematical optimization model obtained in step 4.1; Step 4.3: Determine the feasibility of the scheme and generate feedback: If all constraints are satisfied based on the verification in step 4.2, the site selection scheme is determined to be a feasible scheme, and the site selection scheme is the solution vector output in step 3, i.e., a complete deployment scheme composed of specific new site locations and types; If at least one constraint is not satisfied, the scheme is determined to be infeasible, and all specific constraints violated and their violation degrees are identified; Step 4.4: Transmit verification results and feedback information: If the scheme is feasible and meets the preset stopping condition, output the feasible solution as the final result; If the scheme is infeasible or the solver fails, transmit the detailed verification results to the code generation agent for guidance in the next round of code modification or possible algorithm / parameter adjustment.

6. The multi-agent automated base station siting method based on a large language model driver according to claims 1-5, characterized in that, In step 6, the specific operation steps of online self-healing re-planning include: Step 6.1: KPI acquisition: real-time acquisition of cell-level key performance indicators KPI; Step 6.2: Difference demand generation: after the acquisition of cell-level key performance indicators KPI, calculate the mean and variance of each indicator KPI through the sliding window statistical method, and identify abnormal fluctuations combined with historical distribution characteristics and anomaly detection algorithms; Step 6.3: Call Diff-Prompt submodule: after the difference demand ΔD is generated, trigger the Diff-Prompt submodule to make minimal modifications to the original script S; Step 6.4: Gray verification: the optimization execution agent performs A / B comparison on S and S' in the twin sandbox; if the KPI is improved and there is no constraint violation, it is marked as passed; otherwise, it is determined to fail; Step 6.5: Hot update deployment: patches are hot-loaded to the live network through the CI / CD pipeline, achieving second-level switching; Step 6.6: rollback mechanism: if the gray verification fails or the KPI deteriorates after the patch is put into use, an automatic rollback is performed to restore to the last stable version, and an alarm is generated and a work order is recorded.

7. A multi-agent automated base station siting system driven based on a large language model, characterized in that, Comprise: a problem modeling module configured to understand the problem background and requirements and automatically model them into a mathematical optimization model; a code generation module configured to select a suitable optimization algorithm according to the mathematical optimization model, automatically write corresponding executable code, and correct the executable code according to subsequent feedback; a code execution module configured to execute the generated optimization code and collect and arrange the site selection scheme output by the code; a result evaluation module configured to verify the effectiveness of the output site selection scheme according to the problem requirements and the constraint conditions in the mathematical optimization model, and feed back the verification results to guide further optimization of the code; an online self-healing re-planning module configured to monitor network KPI in real time; if the KPI deviates from the preset threshold, the online self-healing re-planning agent extracts the local difference requirement ΔD; calls the Diff-Prompt sub-module in the code generation agent to make a minimum patch to the previously verified executable code; the optimization execution agent performs A / B verification on the patch through its gray verification sub-module; after verification, the patch is deployed through a hot update mechanism with zero downtime, and the online self-healing re-planning is continuously executed in a loop.

Images