An automated intelligent inspection method based on a large language model

Abstract

This invention discloses an automated intelligent inspection method based on a large language model, comprising the following steps: S1: The large language model receives inspection requests described in natural language by maintenance personnel, performs semantic parsing and element extraction to obtain user intent; S2: The large language model uses the user intent as search terms to generate a script to be executed; S3: The system defines the inspection scope and the script to be executed, issues and executes the script; S4: After receiving the script execution completion signal, the system performs full collection and standardized cleaning of the returned results; S5: The large language model generates an inspection report. This invention improves inspection efficiency across multiple stages through intelligent inspection using large language; clearly identifies and avoids inspection risks; and intelligently identifies problems and provides decision support.

Description

Technical Field

[0001] This invention relates to the field of automated operation and maintenance technology, and in particular to an automated intelligent inspection method based on a large language model. Background Technology

[0002] The current data center has a cluster of over a thousand IT devices, and the equipment system presents a complex layout with multiple brands, architectures, and types coexisting, covering a full stack of IT assets such as physical servers (including minicomputers, x86, c86, ARM architectures), virtual machines, storage arrays, network switches, and firewalls.

[0003] Due to the heterogeneous interface protocols of devices from different manufacturers and the lack of standardized operation and maintenance interfaces, the current operation and maintenance model relies heavily on manual processes. Maintenance personnel must remotely log in to each device one by one via web pages / CLI command lines for troubleshooting, resulting in core pain points such as low efficiency, susceptibility to errors, and difficulty in controlling security risks. Furthermore, the massive amount of isolated inspection report data makes it difficult to extract core issues, time-consuming and laborious in locating the root causes of anomalies, and lacks closed-loop feedback on fault repair status, requiring waiting for the next inspection to confirm the repair results, which significantly impacts business stability.

[0004] Therefore, it is urgent to build an automated system for the entire operation and maintenance inspection process based on large language models. Through AI-assisted intelligent script generation, batch task distribution, automatic collection and interpretation of execution results, intelligent diagnosis of fault root causes and closed-loop repair suggestions, a leap from manual machine-by-machine troubleshooting to automated inspection and fault diagnosis can be achieved, comprehensively covering all scenarios of inspection efficiency, safety compliance and fault closure.

[0005] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to provide an automated intelligent inspection method based on a large language model, thereby solving the problems existing in the background technology.

[0007] To achieve the above objectives, this invention provides an automated intelligent inspection method based on a large language model, characterized by the following steps: S1: The large language model receives inspection requests described in natural language by maintenance personnel, performs semantic parsing and element extraction to obtain user intent; S2: The large language model generates a script to be executed using the user intent as the search term; S3: The system defines the inspection scope and the script to be executed, issues and executes the script; S4: After receiving the script execution completion signal, the system performs full collection and standardized cleaning of the returned results; S5: The large language model generates an inspection report.

[0008] In one embodiment of the present invention, step S1 specifically includes: S11: The system sets up a natural language receiving module; the large language model presets element types as recognition target specifications; the natural language receiving module maintains a long-term waiting state; S12: After recognizing natural language, the natural language receiving module transmits the speech signal to the large language model; S13: The large language model performs semantic parsing, and uses natural language processing technology to extract keywords of natural language through word segmentation and named entity recognition, transforming unstructured data into structured target element types according to the recognition target specifications, and parsing to obtain the user intent.

[0009] In one embodiment of the present invention, in step S1, the element types include: inspection objects, including at least servers, databases, network devices, and application systems; inspection indicators, including at least performance indicators, status indicators, and log indicators; execution frequency, including at least single, timed, and periodic cycles; execution scope, including at least cluster name, business system identifier, asset library dimension label, and device IP range; special requirements, including at least threshold information, result format, and priority; and the user intent includes one or more of the multiple element types.

[0010] In one embodiment of the present invention, step S2 includes: S21: The system allocates storage space, sets up a script library, and defines an upper threshold and a lower threshold, wherein the value of the upper threshold is higher than the lower threshold; S22: The large language model checks script updates, archives successfully executed scripts and the latest script input by the user, and retrieves the user intent; S23-1: The large language model traverses the script library, performs semantic parsing on the user intent, extracts core keyword judgment logic, and matches similar scenario scripts in the local script library; if the matching degree between the existing script in the script library and the user intent is not lower than the upper threshold, then this existing script is selected as the script to be executed, and step S2 ends; S23-2 If the large language model identifies that the matching rate between existing scripts in the script library and the user's intent is lower than the upper threshold but not lower than the lower threshold, the large language model will issue a signal to remind the user and output the top 5 existing scripts in descending order of matching degree; and switch to manual confirmation mode. If the user issues an instruction, the existing script confirmed by the user will be used as the script to be executed, and step S2 will end; S23-3: If the large language model identifies that the matching rate between existing scripts in the script library and the user's intent is lower than the lower threshold, the large language model will remind the user that the matching has failed; wherein, the script library is stored in a three-level classification according to the inspection scenario, object type and script type; each script contains the following three attributes: basic attributes, script content and related information.

[0011] In one embodiment of the present invention, step S2 further includes: S23-4: If the condition of step S23-2 is met, but the user has not issued an instruction within the specified time; or a matching failure instruction is issued within the specified time; or the condition of step S23-3 is met, the user intent is converted into an executable operation and maintenance script using the large language model as the core engine; when generating the script, the large language model automatically injects output field specifications to ensure that all script output structures are consistent and to avoid errors in report interpretation due to format confusion; the output specifications are automatically supplemented, forcing the script output to include five core fields: inspection time, object identifier, indicator name, indicator value, and status, for format consistency. 1. S24: Mark the script, including: after the script is generated, the large model automatically completes the risk level marking, which is divided into query, configuration, modification and deletion, and vulnerability repair and patch installation categories; after the risk level is marked, the system automatically generates a unique script ID and sends the script to the script library cache; the script ID is associated with the script version, applicable scenario, asset dimension tag and other information; among them, the query category is executed and the execution log is recorded; the configuration category is automatically executed after backing up the configuration file; the modification and deletion category and the vulnerability repair and patch installation category are executed after manual review, and the risk level is strongly bound to the execution permission, and the system prohibits bypassing the approval to directly execute high-risk scripts.

[0012] In one embodiment of the present invention, step S3 includes: S31: The system confirms that the script to be executed meets the basic conditions for being sent for execution, as the script metadata has been persisted to the script library; the system reads the script to be executed and, according to the mapping relationship of the script to be executed, creates a new inspection task and an inspection template: the new inspection task includes: the system calls the task creation interface to create a unique inspection task for each selected target device, each task is assigned a globally unique task ID, and associated with core information such as device identifier, script ID, and execution parameters, and the task status is initialized to "pending issuance"; the new inspection template includes: based on demand + multi-dimensional tags of the asset library, the target execution device is accurately screened, and a standard is generated. The system generates a list of devices; simultaneously, based on verification rules, it verifies the completeness of core execution parameters. Required parameters include at least: execution time, number of retries, script ID, and input parameters. The verification rules are: if parameters are missing, the process terminates and a structured exception message is returned; if parameters are complete, an inspection template is generated. The template binding includes at least: task ID, target device list, complete script content, preset execution time, and retry rule configuration, serving as a standardized basis for subsequent steps. The inspection template also includes version management for subsequent traceability and rollback. After a new inspection template is created, it enters a pending confirmation state. The large language model highlights the script based on its risk level, with a specified delay time. If maintenance personnel do not operate within the specified time... If the default risk is acceptable, proceed to the next step. Within the specified time, maintenance personnel can determine whether to execute a risky operation based on the risk level. If the maintenance personnel determine that the risky operation is unacceptable, they can issue a termination command to intercept the system's default operation. S32: Configure the inspection template and read the core configuration within the script to be executed, including at least: associated information, execution time, and target node. S33: The system starts the distributed delivery engine and pushes the execution script to all target devices in parallel. Through a unified data pipeline, the execution script file is delivered to the local Agent of the target device. During the delivery process, the data pipeline transmits the delivery status of each device in real time. If the delivery fails or the device leaves the target device, the system will report the delivery status. The online device automatically records the reason and includes it in the subsequent retry queue; after receiving the execution script, the target device Agent encrypts and caches the execution script in a local specified directory, and generates a download log, which is then sent back to the system log information database; the system performs long-term monitoring by comparing the local time with the execution time; S34: when the template has not reached its execution time, the Agent remains in a "waiting to execute" state, and the system monitors the online status of the device in real time; when the system's local time is consistent with the execution time, the system sends an execution command to the target device Agent; after receiving the execution command, the Agent verifies the MD5 value of the locally cached script, and if the verification passes, it starts the script execution, collecting progress and error information in real time during the execution process;If the script execution times out, the system automatically triggers retry logic, re-issuing the execution command according to the preset number of retries. Each retry records the reason for the retry and the retry time. Monitoring data such as execution progress, execution time, and error logs are transmitted back to the system in real time via data pipelines and stored in a time-series database for subsequent performance analysis and problem localization.

[0013] In one embodiment of the present invention, step S4 includes: S41: collecting the execution results of each target device, supporting both structured and unstructured data, including at least: node IP, execution time, script return value, detailed logs, and reasons for execution exceptions; cleaning the data, filtering invalid data, converting unstructured data into a standard format, verifying data integrity, marking results with missing core fields as "invalid", providing a unified, high-quality data source, and ensuring the integrity, consistency, and traceability of data throughout the process; persisting the standardized result data to the database and pushing it to the inspection report generation program for further data analysis.

[0014] In one embodiment of the present invention, step S5 includes: S51: Data identification and analysis of a large amount of inspection data, including server indicators, network indicators, hardware indicators, log data, and application indicators; S52: A large language model comprehensively summarizes and integrates the inspection data, including overall operational status, statistics of normal / abnormal equipment, trends of key indicators, and time period comparisons; simultaneously, the model automatically identifies abnormal types, including threshold-type abnormalities, trend-type abnormalities, and correlation-type abnormalities; through in-depth analysis by the large language model, root cause judgment and impact scope confirmation are performed; S53: The large language model analyzes the data, performs multi-dimensional statistical analysis according to the inspection content and inspection results; matches different report output templates, groups and statistically analyzes various indicators according to the inspection object / asset dimension, outputs the number and proportion of normal and abnormal data, and outputs the overall inspection situation as an electronic report; when the large language model outputs, it highlights abnormal content or results that exceed the execution expectations, analyzes the fault distribution pattern from a cluster perspective, and clarifies the source and cause of abnormal information. The system includes a routine information display to improve report interpretation efficiency; the electronic report includes keyword retrieval with full-text highlighting of search results for easy and quick location of key information; it also includes report export, capable of generating standard Word / PDF format reports, which can be exported and saved to meet offline viewing and archiving needs; the automated intelligent inspection method based on a large language model also includes step S6, which is automatically executed after the report is generated in step S5; S6: Based on the inspection anomaly results, the large language model intelligently retrieves and matches fault solutions from the operation and maintenance knowledge base and external knowledge base to improve operation and maintenance response efficiency; it extracts anomaly indicators from the report as keywords to retrieve in the operation and maintenance knowledge base and matches solutions for the current anomaly type; when a solution is matched in the knowledge base, standardized repair steps are directly pushed; when no solution is matched, it combines the external knowledge base and pushes troubleshooting suggestions through the large model's own reasoning ability; it tracks the fault repair progress, marks the effectiveness of the suggestions after repair, and records and updates the operation and maintenance knowledge base.

[0015] Secondly, the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the program, implements the aforementioned automated intelligent inspection method based on a large language model.

[0016] Thirdly, the present invention provides a non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the aforementioned automated intelligent inspection method based on a large language model.

[0017] Compared with existing technologies, this invention improves efficiency in multiple stages by leveraging the natural language interaction and automated script generation capabilities of a large language model; it constructs a security closed loop by embedding security and control elements in multiple stages through mechanism design; it not only automates inspections but also utilizes the large language model to achieve intelligent data insight and decision support. Attached Figure Description

[0018] Figure 1 This is an overall flowchart of an automated intelligent inspection method based on a large language model provided by the present invention;

[0019] Figure 2 This is a flowchart of the large language model script generation process for an automated intelligent inspection method based on a large language model, provided by the present invention.

[0020] Figure 3 This is a flowchart of script distribution and execution for an automated intelligent inspection method based on a large language model provided by the present invention.

[0021] Figure 4 This invention provides a flowchart of the large language model report interpretation and operation and maintenance closed-loop process for an automated intelligent inspection method based on a large language model.

[0022] Figure 5 This is a schematic diagram of an inspection report for an automated intelligent inspection method based on a large language model provided by the present invention. Detailed Implementation

[0023] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings, but it should be understood that the scope of protection of the present invention is not limited to the specific embodiments.

[0024] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0025] Example 1:

[0026] This embodiment provides an automated intelligent inspection method based on a large language model, including the following steps:

[0027] S1: The large language model receives the inspection requests described in natural language by the operation and maintenance personnel, performs semantic parsing and element extraction, and obtains the user intent;

[0028] S2: The large language model uses the user's intent as the search term to generate a script to be executed;

[0029] S3: The system defines the inspection scope and the script to be executed, and issues and executes the script to be executed;

[0030] S4: After receiving the script execution completion signal, the system performs full collection and standardized cleaning of the returned results;

[0031] S5: Generate inspection reports using a large language model.

[0032] Specifically, to provide an intelligent large language model capable of recognizing and correctly executing instructions from operations and maintenance personnel, in step S1, operations and maintenance personnel use natural language, such as colloquial, unstandardized, and unstructured speech like "Check the CPU and memory usage of C86 and ARM servers every day at 8 AM," to submit inspection requests to the large language model. The model then performs semantic parsing and element extraction on this input, transforming the unstructured requests into structured and readable user intent. This process converts the colloquial descriptions of the large language model into precise, system-understandable instructions.

[0033] In step S2, the large language model uses the parsed user intent as the core, employing it as search terms to match historical scripts or generate new scripts. Its main logic is: first, it searches the pre-built local script library; if the match is high enough, it directly selects the existing script; if the match fails or is unsuitable, the large model dynamically generates a new executable script.

[0034] In step S3, the system combines the generated script to be executed with a precisely filtered list of inspection target devices and pushes it to the agent program (Agent side) of each target device through the distribution engine. The Agent executes the script based on preset time or conditions, and monitors the execution status and collects progress information in real time.

[0035] In step S4, after each agent completes script execution, the system collects the execution result data. Due to the diverse data sources, the system performs standardized cleaning, filters invalid or erroneous data, verifies data integrity (such as whether key fields are missing), and converts it into a unified standard format to provide a high-quality, structured data source for subsequent analysis.

[0036] S5, as a data visualization tool, generates inspection reports in electronic format, which can be transcoded to change the file format, such as converting to commonly used Word or PDF, and then printed into a paper report.

[0037] In summary, this embodiment constructs an end-to-end automated closed loop with a large language model as the intelligent hub, which improves operation and maintenance efficiency and lowers the threshold; intelligent operation and maintenance improves the accuracy of operation and maintenance; unified operation and maintenance coordination increases consistency, and realizes process closure and traceability.

[0038] In a preferred embodiment of this invention, step S1 specifically includes:

[0039] S11: The system sets up a natural language receiving module; the large language model presets element types as recognition target specifications; the natural language receiving module maintains a long-term waiting state for receiving;

[0040] S12: After recognizing natural language, the natural language receiving module transmits the speech signal to the large language model;

[0041] S13: The large language model performs semantic parsing. Using natural language processing technology, through word segmentation and named entity recognition, keywords of natural language are extracted. Unstructured data is transformed into structured target element types according to the recognition target specifications, and the user intent is obtained through parsing.

[0042] The element types include:

[0043] The inspection targets include at least servers, databases, network devices, and application systems;

[0044] Inspection metrics should include at least performance metrics, status metrics, and log metrics;

[0045] Execution frequency includes at least single execution, timed execution, and periodic loop execution;

[0046] The scope of execution should include at least the cluster name, business system identifier, asset database dimension label, and device IP range;

[0047] Special requirements include at least threshold information, result format, and priority.

[0048] The user intent includes one or more of the aforementioned element types.

[0049] Specifically, this implementation method specifies the detailed steps for receiving, transmitting, and parsing natural language, addressing the issue that existing models heavily rely on manual login operations for each device. One difficulty in achieving intelligentization is the imprecise nature of instructions and ambiguity in understanding. By pre-setting element recognition specifications in S11, a standard dictionary and translation rules are essentially established for AI. The named entity recognition technology in S13 can accurately locate and classify core instruction elements from free text, reducing ambiguity and polysemy. In this process, instruction standardization is also achieved.

[0050] In a preferred embodiment of this example, step S2 includes:

[0051] S21: The system allocates storage space, sets up a script library, and defines an upper threshold and a lower threshold, wherein the value of the upper threshold is higher than the lower threshold;

[0052] S22: The large language model checks script updates, archives successfully executed scripts and the latest script input by the user, and retrieves the user intent;

[0053] S23-1: The large language model traverses the script library, performs semantic parsing on the user's intent, extracts core keyword judgment logic, and matches similar scenario scripts in the local script library; if the matching degree between the existing script in the script library and the user's intent is not lower than the upper threshold, then this existing script is selected as the script to be executed, and step S2 ends.

[0054] S23-2: If the large language model identifies that the matching rate between the existing scripts in the script library and the user's intent is lower than the upper threshold but not lower than the lower threshold, the large language model will issue a signal to remind the user and output the top 5 existing scripts in descending order of matching degree; and switch to manual confirmation mode. If the user issues an instruction, the existing script confirmed by the user will be used as the script to be executed, and step S2 will end.

[0055] S23-3: If the large language model identifies that the matching rate between existing scripts in the script library and the user's intent is lower than the lower threshold, the large language model will remind the user that the matching has failed.

[0056] The script library is stored in a three-level classification system based on inspection scenarios, object types, and script types. Each script contains the following three attributes: basic attributes, script content, and associated information.

[0057] Specifically, step S21 sets the matching degree to two thresholds and three intervals. Preferably, the upper threshold is 0.9, the lower threshold is 0.75, and the interval is [0-0.75, 0.75-0.9, 0.9-1]. Each script contains the following attributes: basic attributes (including script ID, scene tag, applicable object, creation time, version number, risk level), script content (execution code, input parameter list, output fields), and associated information (historical execution success rate, operating system version, mounted file system, and other environmental information). Whenever the system executes step S22, the system checks the previous script execution status. If the previous script was executed successfully, it is stored in the script library as a success case.

[0058] In step S23, the system extracts core keywords (such as "inspection / server / CPU / Linux / FY3H business cluster") to determine the matching degree. Based on the matching degree range, it selects the optimal solution based on differentiation. If an existing script has a matching degree not lower than the upper threshold (≥0.9), the system considers this script to be highly suitable for the current needs and automatically selects it as the "script to be executed," ending the process. This mechanism directly reuses verified, mature, and efficient scripts. If the matching degree of all existing scripts with the user's intent falls between the lower and upper thresholds (≥0.75 and <0.9), the system cannot make a completely autonomous automatic choice. At this time, the large model will send signals to the user, such as interface reminders and sound alarms, listing the top 5 most relevant scripts and their details in descending order of matching degree. The system switches to manual confirmation mode, where the user makes the final decision on whether to select a script. If the highest matching degree is lower than the lower threshold (<0.75), it indicates that there is no suitable reusable script in the script library. The system will also notify the user of a failed match and trigger subsequent dynamic generation logic.

[0059] This implementation method employs refined risk control. Through the automatic reuse of "highly matched scripts" in S23-1, it directly skips the lengthy and risky process of writing scripts from scratch, significantly shortening task initiation time. It also utilizes historically validated scripts to ensure execution success rate and reliability. Furthermore, for scripts with uncertain reliability, S23-2 establishes a manual adjudication mode. When the matching degree is in a gray area, the system returns the decision-making power to the operations personnel with final judgment capabilities, while providing top 5 recommendations to assist in decision-making. This avoids both potential misselections due to AI overconfidence and the inefficiency of manually searching through a massive database of scripts each time. The matching failure condition in S23-3 essentially explores the scope of the script library. Matching failure signifies facing a completely new or unencountered inspection requirement. This triggers subsequent automatic script generation, ensuring the system's ability to handle new requirements. The generated scripts are then archived back into the library, completing the self-updating and knowledge accumulation of the script library, enabling the system to grow.

[0060] Meanwhile, this implementation method specifies that the script library is organized into a three-level classification storage structure, and each script record must include its basic attributes (including script ID, scene tag, applicable object, creation time, version number, risk level), script content (execution code, input parameter list, output fields), and associated information (historical execution success rate, operating system version, mounted file system and other environmental information) to ensure that the information in the library is comprehensive, easy to retrieve and manage.

[0061] In a preferred embodiment of this example, step S2 further includes:

[0062] S23-4: If the conditions of step S23-2 are met, but the user does not issue an instruction within the specified time; or issues a matching failure instruction within the specified time; or if the conditions of step S23-3 are met, the user's intent is converted into an executable operation and maintenance script using the large language model as the core engine; when generating the script, the large language model automatically injects output field specifications to ensure that all script output structures are consistent and to avoid errors in report interpretation due to format confusion; the output specifications are automatically supplemented, forcing the script output to include five core fields: inspection time, object identifier, indicator name, indicator value, and status, for format consistency;

[0063] S24: Mark the script, including: the large model automatically completes the risk level marking after the script is generated, which is divided into query, configuration, modification and deletion, and vulnerability repair and patch installation categories; after the risk level is marked, the system automatically generates a unique script ID and sends the script to the script library cache; the script ID is associated with script version, applicable scenarios, asset dimension tags and other information;

[0064] The query class executes and records execution logs; the configuration class is executed automatically after backing up the configuration file; the modification and deletion class, vulnerability repair and patch installation class are executed after manual review, and the risk level is strongly bound to the execution permission. The system prohibits bypassing the approval process to directly execute high-risk scripts.

[0065] Specifically, in S23-2 mode, if the user fails to operate within the specified time or S23-3 matching fails, the system invokes the core engine of the large language model to directly convert the user's natural language intent into executable computer instructions, which serve as the script to be executed. At the script content level, the large model enforces a unified output format specification for the script to be executed, requiring the generated script to output five standardized fields: inspection time, object identifier, indicator name, indicator value, and status. This ensures that scripts generated by different people for different purposes have completely consistent output structures.

[0066] Step S4 involves archiving the script after adding a unique ID, risk marker, and metadata. This transforms the script from one-off code into a traceable, version-manageable, and risk-level-queryable knowledge asset. This not only facilitates team collaboration but also provides precise data support for subsequent audits, reviews, and optimizations. Query commands include, but are not limited to, `select` and `show`; configuration commands include, but are not limited to, `modify` and `config`; and modification / deletion commands include, but are not limited to, `rm` and `drop`.

[0067] In a preferred embodiment of this example, step S4 includes:

[0068] S31: The system confirms that the script to be executed meets the basic conditions for execution, as the script metadata has been persisted to the script library; the system reads the script to be executed and, based on the mapping relationship of the script to be executed, creates a new inspection task and inspection template:

[0069] The newly created inspection task includes: the system calls the task creation interface to create a unique inspection task for each selected target device, each task is assigned a globally unique task ID, and associated with core information such as device identifier, script ID, and execution parameters, and the task status is initialized to "pending issuance";

[0070] The newly created inspection template includes: precise screening of target execution devices based on demand and multi-dimensional tags from the asset library, generating a standardized device list; simultaneously, based on verification rules, verifying the completeness of core execution parameters, with required parameters including at least: execution time, number of retries, script ID, and input parameters; the verification rules are: if parameters are missing, the process is terminated and a structured exception message is returned; if parameters are complete, an inspection template is generated, and the template binding includes at least: task ID, target device list, complete script content, preset execution time, and retry rule configuration, serving as a standardized basis for subsequent steps. The inspection template also includes version management for subsequent traceability and rollback.

[0071] Once a new inspection template is created, it enters a pending confirmation state. The large language model highlights the script based on its risk level and delays for a specified time. If the maintenance personnel do not perform any operation within the specified time, the risk is assumed to be acceptable, and the next operation is performed. Within the specified time, the maintenance personnel can determine whether to perform a risky operation by confirming the risk level. If the maintenance personnel determine that the risky operation is unacceptable, they can issue a termination command to intercept the system's default operation.

[0072] S32: Configure the inspection template and read the core configuration in the script to be executed, including at least: association information, execution time, and target node;

[0073] S33: The system starts the distributed delivery engine, pushes the execution script to all target devices in parallel, and delivers the execution script file to the local agent of the target device through a unified data pipeline. During the delivery process, the data pipeline transmits the delivery status of each device in real time. Failures or offline devices are automatically recorded and included in the subsequent retry queue. After receiving the execution script, the target device agent encrypts and caches the execution script in a local specified directory, and generates a download log, which is then sent back to the system log information database. The system performs long-term monitoring by comparing the local time with the execution time.

[0074] S34: When the template execution time has not yet arrived, the Agent remains in a "pending execution" state, and the system monitors the online status of the device in real time. When the system's local time matches the execution time, the system sends an execution command to the target device Agent. After receiving the execution command, the Agent verifies the MD5 value of the locally cached script. If the verification passes, the script execution is started, and progress and error information are collected in real time during the execution process. If the script execution times out, the system automatically triggers the retry logic and resends the execution command according to the preset number of retries. The reason for each retry and the retry time are recorded. Monitoring data such as execution progress, time consumption, and error logs are transmitted back to the system in real time through the data pipeline and stored in the time series database for subsequent performance analysis and problem localization.

[0075] Specifically, the process involves creating a unique inspection task for each selected target device, while also supporting the batch creation of unique inspection tasks for multiple devices. If the complexity or number of tasks decreases, the number of batch-created task alternatives will be increased. The requirement refers to the inspection scope after natural language parsing. The asset database uses multi-dimensional tags for node types, including physical machines / virtual machines; other dimensions: data center / application; and identification dimensions: IP / hostname. Required parameters include: execution time (single / periodic), number of retries (preferably 2), script ID, and input parameters (such as inspection indicators and thresholds). The step returns structured exception prompts, including missing parameter types and completion guidance.

[0076] In step S34, before the template's execution time, the Agent remains in a "pending execution" state. The system monitors the device's online status in real time, triggering an alarm if an abnormal offline status occurs. After the template's preset execution time is reached, the system sends an execution command to the target device Agent. Upon receiving the execution command, the Agent verifies the MD5 value of the locally cached script to prevent tampering. If the verification passes, the script execution begins. During execution, progress (such as execution steps, time consumption, and error information, such as command execution failure or insufficient permissions) is collected in real time. If the script execution times out (the timeout threshold is configured by the template), the system automatically triggers retry logic, re-issuing the execution command according to the preset number of retries (default 2 times). Each retry records the retry reason and retry time. Monitoring data such as execution progress, time consumption, and error logs are transmitted back to the system in real time through a data pipeline and stored in a time-series database for subsequent performance analysis and problem localization.

[0077] In a preferred embodiment of this example, step S4 includes:

[0078] S41: Collects the execution results of each target device, supporting both structured and unstructured data, including at least: node IP, execution time, script return value, detailed logs, and reasons for execution exceptions; cleans the data, filters invalid data, converts unstructured data into a standard format, verifies data integrity, marks results missing core fields as "invalid," provides a unified, high-quality data source, and ensures the integrity, consistency, and traceability of data throughout the process; persists the standardized result data to the database and pushes it to the inspection report generation program for further data analysis.

[0079] In a preferred embodiment of this example, step S5 includes:

[0080] S51: Data Identification and Analysis: A large amount of inspection data includes server metrics, network metrics, hardware metrics, log data, and application metrics;

[0081] S52: The large language model comprehensively summarizes and integrates inspection data, including overall operational status, statistics of normal / abnormal equipment, trends of key indicators, and time period comparisons; at the same time, the model automatically identifies anomaly types, including threshold-type anomalies, trend-type anomalies, and correlation-type anomalies; through in-depth analysis by the large language model, root cause judgment and impact scope confirmation are performed.

[0082] S53: The large language model analyzes data, performing multi-dimensional statistical analysis based on inspection content and results; it matches different report output templates, groups and statistically analyzes various indicators by inspection object / asset dimension, outputs the number and percentage of normal and abnormal data, and outputs the overall inspection situation as an electronic report; the large language model output highlights abnormal content or results exceeding expectations, analyzes fault distribution patterns at the cluster level, clarifies the source and display of abnormal information, and improves report interpretation efficiency; the electronic report includes keyword search, with full-text highlighting of search results for quick location of key information; it also includes report export, capable of generating standard Word / PDF format reports, which can be exported and saved to meet offline viewing and archiving needs.

[0083] Specifically, step S51 includes server metrics such as CPU, memory, disk, load, TCP connections, and port status; network metrics such as bandwidth, packet loss, latency, and port traffic; hardware metrics such as CPU, memory, motherboard, power supply, fan, and hard drive; log data such as CPU, memory, motherboard, power supply, fan, and hard drive; and application metrics such as database connection count, resource scheduling process status, and file system utilization.

[0084] In S52, threshold-related anomalies include CPU usage >90% for 5 minutes, memory usage >95%, disk usage >90% / inode exhaustion, etc.; trend-related anomalies include sudden increases / decreases in metrics, continuous increases in memory usage, sudden increases in database connection count, etc.; correlation-related anomalies include slow DB queries → application interface timeouts; full disk → logs cannot be written → service crashes; high data center temperature → multiple servers simultaneously triggering alarms, etc.

[0085] As a preferred embodiment of this example, the automated intelligent inspection method based on a large language model further includes step S6, which is executed automatically after the report is generated in step S5.

[0086] S6: Based on the inspection anomaly results, the large language model intelligently retrieves and matches fault solutions from the operation and maintenance knowledge base and external knowledge base to improve operation and maintenance response efficiency; it extracts the abnormal indicators in the report as keywords to search in the operation and maintenance knowledge base and matches solutions for the current anomaly type; when a solution is matched in the knowledge base, it directly pushes standardized repair steps; when no solution is matched, it combines the external knowledge base and pushes troubleshooting suggestions through the large model's own reasoning ability; it tracks the fault repair progress, marks the effectiveness of the suggestions after repair, and records and updates the operation and maintenance knowledge base.

[0087] Step S6 forms a closed loop of problem discovery, problem solving, and knowledge base review and updating.

[0088] Example 2:

[0089] An electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the program to implement the aforementioned automated intelligent inspection method based on a large language model.

[0090] Example 3:

[0091] A non-transitory computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned automated intelligent inspection method based on a large language model.

[0092] The foregoing description of specific exemplary embodiments of the invention is for illustrative and explanatory purposes. These descriptions are not intended to limit the invention to the precise forms disclosed, and it will be apparent that many changes and variations can be made in accordance with the foregoing teachings. The exemplary embodiments were chosen and described in order to explain the specific principles of the invention and its practical application, thereby enabling those skilled in the art to implement and utilize various different exemplary embodiments of the invention, as well as various different choices and variations. The scope of the invention is intended to be defined by the claims and their equivalents.

Claims

1. An automatic intelligent inspection method based on a large language model, characterized in that, Includes the following steps: S1: The large language model receives the inspection requests described in natural language by the operation and maintenance personnel, performs semantic parsing and element extraction, and obtains the user intent; S2: The large language model uses the user's intent as the search term to generate a script to be executed; S3: The system defines the inspection scope and the script to be executed, and issues and executes the script to be executed; S4: After receiving the script execution completion signal, the system performs full collection and standardized cleaning of the returned results; S5: Generate inspection reports using a large language model.

2. The automatic intelligent patrol method based on a large language model according to claim 1, wherein, Step S1 specifically includes: S11: The system sets up a natural language receiving module; the large language model presets element types as recognition target specifications; the natural language receiving module maintains a long-term waiting state for receiving; S12: After recognizing natural language, the natural language receiving module transmits the speech signal to the large language model; S13: The large language model performs semantic parsing. Using natural language processing technology, through word segmentation and named entity recognition, keywords of natural language are extracted. Unstructured data is transformed into structured target element types according to the recognition target specifications, and the user intent is obtained through parsing.

3. The automated intelligent patrol method based on a large language model of claim 2, wherein, In step S1, the feature types include: The inspection targets include at least servers, databases, network devices, and application systems; Inspection metrics should include at least performance metrics, status metrics, and log metrics; Execution frequency includes at least single execution, timed execution, and periodic loop execution; The scope of execution should include at least the cluster name, business system identifier, asset database dimension label, and device IP range; Special requirements include at least threshold information, result format, and priority. The user intent includes one or more of the aforementioned element types.

4. The automatic intelligent patrol method based on a large language model of claim 3, wherein, Step S2 includes: S21: The system allocates storage space, sets up a script library, and defines an upper threshold and a lower threshold, wherein the value of the upper threshold is higher than the lower threshold; S22: The large language model checks script updates, archives successfully executed scripts and the latest script input by the user, and retrieves the user intent; S23-1: The large language model traverses the script library, performs semantic parsing on the user's intent, extracts core keyword judgment logic, and matches similar scenario scripts in the local script library; if the matching degree between the existing script in the script library and the user's intent is not lower than the upper threshold, then this existing script is selected as the script to be executed, and step S2 ends. S23-2: If the large language model identifies that the matching rate between the existing scripts in the script library and the user's intent is lower than the upper threshold but not lower than the lower threshold, the large language model will issue a signal to remind the user and output the top 5 existing scripts in descending order of matching degree; and switch to manual confirmation mode. If the user issues an instruction, the existing script confirmed by the user will be used as the script to be executed, and step S2 will end. S23-3: If the large language model identifies that the matching rate between existing scripts in the script library and the user's intent is lower than the lower threshold, the large language model will remind the user that the matching has failed. The script library is stored in a three-level classification system based on inspection scenarios, object types, and script types. Each script contains the following three attributes: basic attributes, script content, and associated information.

5. The automatic intelligent patrol method based on a large language model according to claim 4, wherein, Step S2 further includes: S23-4: If the conditions of step S23-2 are met, but the user does not issue an instruction within the specified time; or issues a matching failure instruction within the specified time; or if the conditions of step S23-3 are met, the user's intent is converted into an executable operation and maintenance script using the large language model as the core engine; when generating the script, the large language model automatically injects output field specifications to ensure that all script output structures are consistent and to avoid errors in report interpretation due to format confusion; the output specifications are automatically supplemented, forcing the script output to include five core fields: inspection time, object identifier, indicator name, indicator value, and status, for format consistency; S24: Mark the script, including: the large model automatically completes the risk level marking after the script is generated, which is divided into query, configuration, modification and deletion, and vulnerability repair and patch installation categories; after the risk level is marked, the system automatically generates a unique script ID and sends the script to the script library cache; the script ID is associated with script version, applicable scenarios, asset dimension tags and other information; The query class executes and records execution logs; the configuration class is executed automatically after backing up the configuration file; the modification and deletion class, vulnerability repair and patch installation class are executed after manual review, and the risk level is strongly bound to the execution permission. The system prohibits bypassing the approval process to directly execute high-risk scripts.

6. The automated intelligent patrol method based on a large language model of claim 5, wherein, Step S3 includes: S31: The system confirms that the script to be executed meets the basic conditions for execution, as the script metadata has been persisted to the script library; the system reads the script to be executed and, based on the mapping relationship of the script to be executed, creates a new inspection task and inspection template: The newly created inspection task includes: the system calls the task creation interface to create a unique inspection task for each selected target device, each task is assigned a globally unique task ID, and associated with core information such as device identifier, script ID, and execution parameters, and the task status is initialized to "pending issuance"; The newly created inspection template includes: precise screening of target execution devices based on demand and multi-dimensional tags from the asset library, generating a standardized device list; simultaneously, based on verification rules, verifying the completeness of core execution parameters, with required parameters including at least: execution time, number of retries, script ID, and input parameters; the verification rules are: if parameters are missing, the process is terminated and a structured exception message is returned; if parameters are complete, an inspection template is generated, and the template binding includes at least: task ID, target device list, complete script content, preset execution time, and retry rule configuration, serving as a standardized basis for subsequent steps. The inspection template also includes version management for subsequent traceability and rollback. Once a new inspection template is created, it enters a pending confirmation state. The large language model highlights the script based on its risk level and delays for a specified time. If the maintenance personnel do not perform any operation within the specified time, the risk is assumed to be acceptable, and the next operation is performed. Within the specified time, the maintenance personnel can determine whether to perform a risky operation by confirming the risk level. If the maintenance personnel determine that the risky operation is unacceptable, they can issue a termination command to intercept the system's default operation. S32: Configure the inspection template and read the core configuration in the script to be executed, including at least: association information, execution time, and target node; S33: The system starts the distributed delivery engine, pushes the execution script to all target devices in parallel, and delivers the execution script file to the local agent of the target device through a unified data pipeline. During the delivery process, the data pipeline transmits the delivery status of each device in real time. Failures or offline devices are automatically recorded and included in the subsequent retry queue. After receiving the execution script, the target device agent encrypts and caches the execution script in a local specified directory, and generates a download log, which is then sent back to the system log information database. The system performs long-term monitoring by comparing the local time with the execution time. S34: When the template execution time has not yet arrived, the Agent remains in a "pending execution" state, and the system monitors the online status of the device in real time. When the system's local time matches the execution time, the system sends an execution command to the target device Agent. After receiving the execution command, the Agent verifies the MD5 value of the locally cached script. If the verification passes, the script execution is started, and progress and error information are collected in real time during the execution process. If the script execution times out, the system automatically triggers the retry logic and resends the execution command according to the preset number of retries. The reason for each retry and the retry time are recorded. Monitoring data such as execution progress, time consumption, and error logs are transmitted back to the system in real time through the data pipeline and stored in the time series database for subsequent performance analysis and problem localization.

7. The automated intelligent patrol method based on a large language model of claim 6, wherein, Step S4 includes: S41: Collects the execution results of each target device, supporting both structured and unstructured data, including at least: node IP, execution time, script return value, detailed logs, and reasons for execution exceptions; cleans the data, filters invalid data, converts unstructured data into a standard format, verifies data integrity, marks results missing core fields as "invalid," provides a unified, high-quality data source, and ensures the integrity, consistency, and traceability of data throughout the process; persists the standardized result data to the database and pushes it to the inspection report generation program for further data analysis.

8. The automated intelligent inspection method based on a large language model as described in claim 7, characterized in that, Step S5 includes: S51: Data Identification and Analysis: A large amount of inspection data includes server metrics, network metrics, hardware metrics, log data, and application metrics; S52: The large language model comprehensively summarizes and integrates inspection data, including overall operational status, statistics of normal / abnormal equipment, trends of key indicators, and time period comparisons; at the same time, the model automatically identifies anomaly types, including threshold-type anomalies, trend-type anomalies, and correlation-type anomalies; through in-depth analysis by the large language model, root cause judgment and impact scope confirmation are performed. S53: The large language model analyzes data, performing multi-dimensional statistical analysis based on inspection content and results; it matches different report output templates, groups and statistically analyzes various indicators by inspection object / asset dimension, outputs the number and percentage of normal and abnormal data, and outputs the overall inspection situation as an electronic report; the large language model output highlights abnormal content or results exceeding expectations, analyzes fault distribution patterns at the cluster level, clarifies the source and display of abnormal information, and improves report interpretation efficiency; the electronic report includes keyword search, with full-text highlighting of search results for quick location of key information; it also includes report export, capable of generating standard Word / PDF format reports, exporting and saving them for offline viewing and archiving needs. The automated intelligent inspection method based on a large language model further includes step S6, which is executed automatically after the report is generated in step S5. S6: Based on the inspection anomaly results, the large language model intelligently retrieves and matches fault solutions from the operation and maintenance knowledge base and external knowledge base to improve operation and maintenance response efficiency; it extracts the abnormal indicators in the report as keywords to search in the operation and maintenance knowledge base and matches solutions for the current anomaly type; when a solution is matched in the knowledge base, it directly pushes standardized repair steps; when no solution is matched, it combines the external knowledge base and pushes troubleshooting suggestions through the large model's own reasoning ability; it tracks the fault repair progress, marks the effectiveness of the suggestions after repair, and records and updates the operation and maintenance knowledge base.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the program, it implements an automated intelligent inspection method based on a large language model as described in any one of claims 1-8.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements an automated intelligent inspection method based on a large language model as described in any one of claims 1-8.

Images