Intelligent equipment software exception retrieval method based on AI large model

Abstract

The invention discloses an AI large model-based intelligent equipment software exception retrieval method, which comprises the following steps of: S1, monitoring the running state of equipment software in real time by a built-in monitoring module-exception detection module of intelligent equipment, capturing an exception event, and triggering a data collection mechanism once an exception is detected; s2, the data collection and preprocessing module collects equipment state information when an exception occurs, the collected exception data is stored in a local storage of the intelligent equipment, and the collected information is subjected to preliminary data cleaning and formatting; according to the method, the intelligent device is monitored in real time, related abnormal data are automatically captured, the collected abnormal data are analyzed in cooperation with the multi-mode AI model, the abnormal type is recognized, possible fault causes are diagnosed, fine-grained positioning of the abnormal root causes is achieved, the method exceeds a traditional rule matching method, long-term dependence on manpower is not needed, and the method is simple and convenient to operate. Therefore, the detection efficiency and accuracy are improved.

Description

Technical Field

[0001] This invention relates to the field of intelligent retrieval device software technology, and in particular to an anomaly detection method for intelligent retrieval device software based on a large AI model. Background Technology

[0002] With the widespread application of IoT devices, device anomaly detection has become crucial to ensuring normal device operation. Traditional anomaly detection methods rely on manually set rules, resulting in low detection efficiency and low accuracy. To address this, this application proposes an intelligent method for retrieving device software anomalies based on an AI large model. Summary of the Invention

[0003] Based on the technical problems existing in the background technology, this invention proposes a method for handling software anomalies in intelligent retrieval devices based on a large AI model.

[0004] This invention proposes a method for addressing software anomalies in intelligent retrieval devices based on large AI models, comprising the following steps:

[0005] S1: The built-in monitoring module of the smart device—the anomaly detection module—monitors the running status of the device software in real time, captures abnormal events, and triggers the data collection mechanism once an anomaly is detected.

[0006] S2: The data collection and preprocessing module collects device status information when an anomaly occurs. The collected anomaly data will be stored in the local storage of the smart device, and the collected information will be preliminarily cleaned and formatted.

[0007] S3: The AI ​​large model analysis and suggestion generation module trains a multimodal AI large model based on historical fault datasets, enabling the multimodal AI large model to support natural language processing (NLP) and code semantic analysis;

[0008] S4: Input the preprocessed data from S2 into the multimodal AI large model trained in S3. The multimodal AI large model outputs analysis results. The AI ​​large model analysis and suggestion generation module generates detailed fault reports and solution suggestions based on these results.

[0009] S5: The anomaly detection module reports the collected anomaly data to the cloud server. Before uploading the data to the cloud server, it displays an authorization request pop-up to the user and clearly informs the user of the authorization purpose and data usage. After the user confirms the authorization, the system encrypts the data and uploads it to the cloud server.

[0010] S6: The cloud server receives and stores the uploaded data, and provides a secure access interface for the after-sales team. Engineers need to be authenticated and authorized to access the data of specific devices.

[0011] S7: After-sales engineers log in to the management backend, query and analyze the uploaded fault data, and troubleshoot and repair the faults based on the suggestions provided by the multimodal AI big model in S4.

[0012] Preferably, in step S1, the specific steps for capturing abnormal events are as follows:

[0013] S101: When a smart device starts up, it automatically starts a background monitoring module—an anomaly detection module;

[0014] S102: The anomaly detection module monitors the software's running status in real time through periodic checks or event-driven methods. The monitored content includes, but is not limited to: whether the software crashes, whether the software reports errors, and whether the software's performance indicators are abnormal.

[0015] S103: Once an abnormal event is detected, the data collection mechanism is immediately triggered. The data collection mechanism is to collect the device status information when the abnormality occurs through the data collection and preprocessing module in S2.

[0016] Preferably, in step S2, the data collection mechanism collects device status information at the time of the anomaly through the data collection and preprocessing module, including but not limited to log files, system parameters, hardware status, and user operation records. The log files include system logs, application logs, and software logs. The software logs include error codes, stack traces, and thread status. The hardware includes CPU utilization, memory usage, temperature, and network status. The user operation records include the sequence of operations before the anomaly was triggered. In addition, when the anomaly is caused by a software crash, the stack information at the time of the crash is collected for subsequent analysis.

[0017] Preferably, in S3, the historical fault dataset includes labeled anomaly types, root causes, and solutions.

[0018] Preferably, in step S4, the analysis results output by the multimodal AI large model include anomaly type classification, root cause localization, and remediation suggestions. The output is modularized, and the suggestions are encapsulated into one of the following: an executable script, a configuration guide, or a graphic operation manual.

[0019] Preferably, in step S5, when the anomaly detection module reports the collected anomaly data to the cloud server, it needs to format the data to a format suitable for transmission.

[0020] The specific steps for encrypting the data are as follows:

[0021] S501: Encryption Algorithm Selection: Employs the industry-standard encryption algorithm AES-256 for symmetric encryption;

[0022] S502: Generate Key: The system automatically generates a random encryption key. This key is generated and stored locally on the device and will not be transmitted over the network to prevent key leakage.

[0023] S503: Encrypt Data: Encrypt collected anomalous data using the generated key, overwriting all sensitive information, including log files, system status, and crash stacks, to ensure that the data content cannot be read by unauthorized parties;

[0024] S504: Key Management: Encrypted data will be stored separately from the key, which will be protected by a secure key management system. Only authorized systems and users can access the decryption key.

[0025] S505: Data transmission: The encrypted data is uploaded to the cloud server through a secure network protocol. During the transmission process, the data remains encrypted to prevent it from being intercepted or tampered with.

[0026] S506: After receiving the encrypted data, the cloud server will use the corresponding key to decrypt it so that the after-sales team can analyze and process it. The decryption process will be carried out in a secure server environment to ensure data security.

[0027] Preferably, in step S5, after data collection and reporting, the anomaly detection module will take corresponding processing measures according to the anomaly type, as follows:

[0028] (1) If the anomaly is caused by a software crash, the anomaly detection module will attempt to automatically restart the application to restore the service;

[0029] (2) If the anomaly is caused by insufficient resources, the anomaly detection module will clean up unnecessary resources to alleviate system pressure;

[0030] (3) In some cases, the monitoring module will notify the user of abnormal situations and provide corresponding solutions;

[0031] After handling the anomaly, the anomaly detection module will return to normal and continue to monitor the software's running status in real time. The anomaly detection module will remain running until the device is shut down or the anomaly detection module is explicitly stopped.

[0032] Preferably, in step S7, the management backend supports sending repair commands to the device with one click, and also supports remote connection to the device to execute diagnostic scripts.

[0033] Compared with existing technologies, the beneficial effects of this invention are:

[0034] 1. By combining an automated anomaly data collection mechanism with multimodal AI large model analysis and diagnosis, it can identify anomaly types and diagnose possible causes of failures, and provide modular modification suggestions and suggestions for the causes of problems based on historical data and pattern recognition;

[0035] 2. By setting up a data upload mechanism, uploaded data can be encrypted and will only be uploaded after obtaining explicit authorization from the user, ensuring user privacy is protected and improving data security.

[0036] 3. By providing a management backend, engineers can query and analyze fault data stored in the cloud, and can convert repair solutions into instructions that can be executed automatically, reducing the operational threshold for engineers;

[0037] This invention automatically captures relevant abnormal data by real-time monitoring of intelligent devices, and analyzes the collected abnormal data in conjunction with a multimodal AI model to identify the type of abnormality and diagnose possible causes of failure. This enables fine-grained localization of the root cause of abnormalities, surpassing traditional rule matching methods and eliminating the need for long-term reliance on manual labor, thereby improving detection efficiency and accuracy. Attached Figure Description

[0038] Figure 1 This is a flowchart of a software anomaly method for an intelligent retrieval device based on a large AI model, as proposed in this invention. Detailed Implementation

[0039] The present invention will be further explained below with reference to specific embodiments.

[0040] Example

[0041] Reference Figure 1 This embodiment proposes a method for handling software anomalies in intelligent retrieval devices based on a large AI model, including the following steps:

[0042] S1: The built-in monitoring module of the smart device—the anomaly detection module—monitors the running status of the device software in real time, captures abnormal events, and triggers the data collection mechanism once an anomaly is detected.

[0043] The specific steps for capturing abnormal events are as follows:

[0044] S101: When a smart device starts up, it automatically starts a background monitoring module—an anomaly detection module;

[0045] S102: The anomaly detection module monitors the software's running status in real time through periodic checks or event-driven methods. The monitored content includes, but is not limited to: whether the software crashes (e.g., the application is unresponsive or forcibly closed), whether the software reports errors (e.g., runtime errors, insufficient resources, etc.), and whether the software's performance indicators are abnormal (e.g., CPU utilization, memory usage, etc.).

[0046] S103: Once an abnormal event is detected, the data collection mechanism is immediately triggered. The data collection mechanism is to collect the device status information when the abnormality occurs through the data collection and preprocessing module in S2.

[0047] S2: The data collection and preprocessing module collects device status information when an anomaly occurs. The collected anomaly data will be stored in the local storage of the smart device, and the collected information will be preliminarily cleaned and formatted.

[0048] The data collection mechanism collects device status information at the time of an anomaly through the data collection and preprocessing module, including but not limited to log files, system parameters, hardware status, and user operation records. The log files include system logs, application logs, and software logs. The software logs include error codes, stack traces, and thread status. The hardware includes CPU utilization, memory usage, temperature, and network status. The user operation records include the sequence of operations before the anomaly was triggered. In addition, when the anomaly is caused by a software crash, the stack information at the time of the crash is collected for subsequent analysis.

[0049] S3: The AI ​​large model analysis and suggestion generation module trains a multimodal AI large model based on a historical fault dataset, enabling the multimodal AI large model to support natural language processing (NLP) and code semantic analysis. The historical fault dataset includes labeled anomaly types, root causes, and solutions.

[0050] S4: Input the preprocessed data from S2 into the multimodal AI large model trained in S3. The multimodal AI large model outputs analysis results. The AI ​​large model analysis and suggestion generation module generates detailed fault reports and solution suggestions based on these results.

[0051] The analysis results output by the multimodal AI large model include anomaly type classification, root cause localization, and remediation suggestions. The output is modularized, and the suggestions are packaged into one of the following: an executable script, a configuration guide, or a graphic operation manual.

[0052] S5: The anomaly detection module reports the collected anomaly data to the cloud server. Before uploading the data to the cloud server, it displays an authorization request pop-up to the user and clearly informs the user of the authorization purpose and data usage. After the user confirms the authorization, the system encrypts the data and uploads it to the cloud server.

[0053] When the anomaly detection module reports the collected anomaly data to the cloud server, it needs to format the data into a format suitable for transmission.

[0054] The specific steps for encrypting the data are as follows:

[0055] S501: Encryption Algorithm Selection: The industry-standard AES-256 encryption algorithm is used for symmetric encryption; alternatively, different encryption algorithms can be selected depending on the situation. This algorithm offers high security and fast processing speed, making it suitable for encrypting large amounts of data.

[0056] S502: Generate Key: The system automatically generates a random encryption key. This key is generated and stored locally on the device and will not be transmitted over the network to prevent key leakage.

[0057] S503: Encrypt Data: Encrypt collected anomalous data using the generated key, overwriting all sensitive information, including log files, system status, and crash stacks, to ensure that the data content cannot be read by unauthorized parties;

[0058] S504: Key Management: Encrypted data will be stored separately from the key, which will be protected by a secure key management system. Only authorized systems and users can access the decryption key.

[0059] S505: Data transmission: Encrypted data is uploaded to the cloud server via a secure network protocol (such as HTTPS / TLS). During transmission, the data remains encrypted to prevent it from being intercepted or tampered with.

[0060] S506: After receiving the encrypted data, the cloud server will use the corresponding key to decrypt it so that the after-sales team can analyze and process it. The decryption process will be carried out in a secure server environment to ensure data security.

[0061] In addition, after data collection and reporting are completed, the anomaly detection module will take corresponding measures based on the anomaly type. The measures are as follows:

[0062] (1) If the anomaly is caused by a software crash, the anomaly detection module will attempt to automatically restart the application to restore the service;

[0063] (2) If the anomaly is caused by insufficient resources, the anomaly detection module will clean up unnecessary resources to alleviate system pressure;

[0064] (3) In some cases, the monitoring module will notify the user of abnormal situations and provide corresponding solutions;

[0065] After handling the anomaly, the anomaly detection module will return to normal and continue to monitor the software's running status in real time. The anomaly detection module will continue to run until the device is shut down or the anomaly detection module is explicitly stopped.

[0066] S6: The cloud server receives and stores the uploaded data, and provides a secure access interface for the after-sales team. Engineers need to be authenticated and authorized to access the data of specific devices.

[0067] S7: After-sales engineers log in to the management backend, query and analyze the uploaded fault data, and troubleshoot and repair the faults based on the suggestions provided by the multimodal AI big model in S4;

[0068] The management backend supports one-click issuance of repair commands to the device, and also supports remote connection to the device to execute diagnostic scripts;

[0069] This embodiment automatically captures relevant abnormal data by monitoring smart devices in real time, and analyzes the collected abnormal data with the help of a multimodal AI model to identify the type of abnormality and diagnose possible causes of failure. This achieves fine-grained localization of the root cause of the abnormality, surpassing traditional rule matching methods and eliminating the need for long-term reliance on manual labor, thereby improving detection efficiency and accuracy.

[0070] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for handling software anomalies in intelligent retrieval devices based on large AI models, characterized in that: Includes the following steps: S1: The built-in monitoring module of the smart device—the anomaly detection module—monitors the running status of the device software in real time, captures abnormal events, and triggers the data collection mechanism once an anomaly is detected. S2: The data collection and preprocessing module collects device status information when an anomaly occurs. The collected anomaly data will be stored in the local storage of the smart device, and the collected information will be preliminarily cleaned and formatted. S3: The AI ​​large model analysis and suggestion generation module trains a multimodal AI large model based on historical fault datasets, enabling the multimodal AI large model to support natural language processing (NLP) and code semantic analysis; S4: Input the preprocessed data from S2 into the multimodal AI large model trained in S3. The multimodal AI large model outputs analysis results. The AI ​​large model analysis and suggestion generation module generates detailed fault reports and solution suggestions based on these results. S5: The anomaly detection module reports the collected anomaly data to the cloud server. Before uploading the data to the cloud server, it displays an authorization request pop-up to the user and clearly informs the user of the authorization purpose and data usage. After the user confirms the authorization, the system encrypts the data and uploads it to the cloud server. S6: The cloud server receives and stores the uploaded data, and provides a secure access interface for the after-sales team. Engineers need to be authenticated and authorized to access the data of specific devices. S7: After-sales engineers log in to the management backend, query and analyze the uploaded fault data, and troubleshoot and repair the faults based on the suggestions provided by the multimodal AI big model in S4.

2. The method for handling software anomalies in intelligent retrieval devices based on large AI models according to claim 1, characterized in that, In step S1, the specific steps for capturing abnormal events are as follows: S101: When a smart device starts up, it automatically starts a background monitoring module—an anomaly detection module; S102: The anomaly detection module monitors the software's running status in real time through periodic checks or event-driven methods. The monitored content includes, but is not limited to: whether the software crashes, whether the software reports errors, and whether the software's performance indicators are abnormal. S103: Once an abnormal event is detected, the data collection mechanism is immediately triggered. The data collection mechanism is to collect the device status information when the abnormality occurs through the data collection and preprocessing module in S2.

3. The method for handling software anomalies in intelligent retrieval devices based on large AI models according to claim 1, characterized in that, In S2, the data collection mechanism collects device status information at the time of the anomaly through the data collection and preprocessing module, including but not limited to log files, system parameters, hardware status, and user operation records. The log files include system logs, application logs, and software logs. The software logs include error codes, stack traces, and thread status. The hardware includes CPU utilization, memory usage, temperature, and network status. The user operation records include the sequence of operations before the anomaly was triggered. In addition, when the anomaly is caused by a software crash, the stack information at the time of the crash is collected for subsequent analysis.

4. The method for handling software anomalies in intelligent retrieval devices based on large AI models according to claim 1, characterized in that, In S3, the historical fault dataset includes labeled anomaly types, root causes, and solutions.

5. The method for handling software anomalies in intelligent retrieval devices based on large AI models according to claim 1, characterized in that, In S4, the analysis results output by the multimodal AI large model include anomaly type classification, root cause localization, and remediation suggestions. The output is modularized, and the suggestions are encapsulated into one of the following: an executable script, a configuration guide, or a graphic operation manual.

6. The method for handling software anomalies in intelligent retrieval devices based on large AI models according to claim 1, characterized in that, In S5, when the anomaly detection module reports the collected anomaly data to the cloud server, it needs to format the data and format the collected anomaly data into a format suitable for transmission. The specific steps for encrypting the data are as follows: S501: Encryption Algorithm Selection: Employs the industry-standard encryption algorithm AES-256 for symmetric encryption; S502: Generate Key: The system automatically generates a random encryption key. This key is generated and stored locally on the device and will not be transmitted over the network to prevent key leakage. S503: Encrypt Data: Encrypt collected anomalous data using the generated key, overwriting all sensitive information, including log files, system status, and crash stacks, to ensure that the data content cannot be read by unauthorized parties; S504: Key Management: Encrypted data will be stored separately from the key, which will be protected by a secure key management system. Only authorized systems and users can access the decryption key. S505: Data transmission: The encrypted data is uploaded to the cloud server through a secure network protocol. During the transmission process, the data remains encrypted to prevent it from being intercepted or tampered with. S506: After receiving the encrypted data, the cloud server will use the corresponding key to decrypt it so that the after-sales team can analyze and process it. The decryption process will be carried out in a secure server environment to ensure data security.

7. The method for handling software anomalies in intelligent retrieval devices based on large AI models according to claim 1, characterized in that, In step S5, after data collection and reporting are completed, the anomaly detection module will take corresponding processing measures according to the anomaly type. The processing measures are as follows: (1) The anomaly is caused by a software crash. The anomaly detection module will attempt to automatically restart the application to restore the service. (2) The anomaly is caused by insufficient resources. The anomaly detection module will clean up unnecessary resources to alleviate system pressure. (3) In some cases, the monitoring module will notify the user of abnormal situations and provide corresponding solutions; After handling the anomaly, the anomaly detection module will return to normal and continue to monitor the software's running status in real time. The anomaly detection module will remain running until the device is shut down or the anomaly detection module is explicitly stopped.

8. The method for handling software anomalies in intelligent retrieval devices based on AI large models according to claim 1, characterized in that, In S7, the management backend supports one-click issuance of repair commands to the device, and also supports remote connection to the device to execute diagnostic scripts.

Images