Low-code-platform-oriented artificial intelligence auxiliary anomaly monitoring and self-repairing method and device, processor and storage medium thereof

Abstract

The invention relates to a low-code platform-oriented artificial intelligence auxiliary anomaly monitoring and self-repairing method, which comprises the following steps of: constructing a system integrated with an anomaly monitoring engine and an AI (Artificial Intelligence) self-repairing engine; real-time collection and feature extraction are carried out on full-stack anomalies (including front-end form rendering anomalies and rear-end API service anomalies) generated when a low-code platform runs. A pre-trained deep learning model is used for carrying out intelligent classification and root cause analysis on anomalies, and based on a knowledge graph and a code completion model, a repair scheme (such as front-end component attribute correction, back-end API calling parameter calibration and the like) is automatically generated for identified common and reproducible anomalies and applied, so that self-repair of the system is realized. The invention also relates to a corresponding device, a processor and a computer readable storage medium. According to the technical scheme, the manual intervention cost of the low-code application in the development, operation and maintenance stages is effectively reduced, and the stability and the development, operation and maintenance efficiency of the application are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and particularly to the cross-disciplinary field of low-code development platforms and artificial intelligence operations and maintenance (AIOps). Specifically, it refers to an artificial intelligence-assisted anomaly monitoring and self-repair method, device, processor, and computer-readable storage medium for low-code platforms. Background Technology

[0002] Low-code development platforms significantly reduce the development threshold and cycle time of software applications through visual drag-and-drop and model-driven approaches. These platforms typically allow users to generate metadata models (usually in JSON format) that match business descriptions via drag-and-drop configuration, and dynamically parse and render them at runtime. However, as application business scenarios become more complex, various problems caused by configuration errors, data anomalies, and environmental differences inevitably arise during the development, testing, and runtime phases. Traditionally, relying on developers to review logs and debug code to locate and fix problems is inefficient and requires high levels of expertise, which contradicts the efficiency-enhancing purpose of low-code platforms.

[0003] In current technological practices, anomaly management for application systems typically follows a passive, reactive paradigm. This paradigm relies heavily on a set of independent monitoring tools and processes that depend heavily on manual intervention.

[0004] Specifically, the implementation can be broken down as follows: At the front-end level, the common approach is to utilize JavaScript's built-in global error handling mechanisms, such as `window.onerror` or error handling hooks provided by front-end frameworks (such as `Vue.config.errorHandler`). These mechanisms can intercept runtime exceptions, script loading failures, and Promise rejections occurring in the browser environment. Once an exception is caught, a common practice is to call a unified logging interface to send the error information, stack trace, and possible user operation context to the backend log server.

[0005] At the backend level, Spring Boot-based microservice architectures typically integrate a suite of mature monitoring ecosystem components. For example, Spring Boot Actuator exposes application health status, metrics, and management endpoints; integration with logging frameworks like Logback or Log4j2 outputs application logs to specified files; and log collection proxies (such as Filebeat or Fluentd) aggregate log files scattered across various microservice instances and transmit them to a centralized log management system (such as the ELK Stack: Elasticsearch, Logstash) for storage, indexing, and retrieval. Simultaneously, application performance management (APM) tools (such as SkyWalking) are widely deployed, collecting service call traces, performance metrics, and anomaly information in a non-intrusive manner.

[0006] When any of the above systems detects an anomaly or performance metrics exceed a threshold, an alarm notification will be triggered through pre-configured rules (usually sent to operations or development personnel via email, SMS, or instant messaging tools such as DingTalk / WeChat Work). Upon receiving the alarm, technical personnel need to manually log in to the corresponding log management or APM system console, write query statements, filter conditions, and combine their own experience to backtrack and analyze massive amounts of logs and link information to try to locate the root cause of the anomaly. After determining the root cause, the source code, configuration files, and databases are manually modified, and the application is redeployed after testing to complete the repair. The entire process, from the occurrence of the anomaly to the final repair, involves numerous steps and heavily relies on the technical skills and experience of technical personnel, forming an open-loop manual processing chain.

[0007] The implementation process of the above-mentioned existing technical solutions has the following main shortcomings: (1) Passive lag: Traditional monitoring only alerts after an anomaly occurs, and cannot predict or intervene in time, which may cause the system to be unavailable for a period of time.

[0008] (2) Low efficiency of root cause analysis: The abnormal information, logs, metrics data and other sources are heterogeneous, and manual correlation analysis is time-consuming and laborious, making it difficult to quickly and accurately locate the specific erroneous configuration items in low-code applications.

[0009] (3) Lack of automated repair capabilities: Existing solutions stop at "discovering problems," and the repair process relies entirely on manual operation, which cannot form a closed loop. For a large number of exceptions in low-code platforms caused by configuration errors and fixed patterns (such as components binding non-existent entity model fields as default values, null pointer errors caused by data anomalies, etc.), there is full potential for automated repair, but existing technologies have failed to achieve this. Summary of the Invention

[0010] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method that can proactively and in real-time monitor full-stack anomalies in low-code applications and use artificial intelligence technology for intelligent root cause analysis and automated repair, thereby forming a complete closed loop from "anomaly perception" to "problem repair", significantly reducing the cost of manual intervention and improving the robustness and operational efficiency of low-code applications.

[0011] To achieve the above objectives, the present invention provides an AI-assisted anomaly detection and self-repair method, apparatus, processor, and computer-readable storage medium for low-code platforms as follows: The main feature of this AI-assisted anomaly detection and self-repair method for low-code platforms is that the method includes the following steps: (1) By deploying exception interceptors on the front end of the low-code application and exception aspects on the back end, full-stack exceptions generated during application runtime are captured in real time, and exception data containing low-code platform metamodel context information is collected. (2) The abnormal data is processed by the AI ​​analysis engine. The abnormal data is transformed into feature vectors through the feature engineering module. The abnormalities are classified by the deep learning classification model. The root cause of the abnormality is located by reasoning in combination with the pre-built low-code domain knowledge graph through the knowledge graph reasoning module. (3) Based on the obtained root cause localization results, a repair solution is generated by the self-repair engine; the self-repair engine matches predefined rules through the rule template library or dynamically generates repair code or configuration patches through the code generation model, and implements the repair.

[0012] Preferably, in step (1), the exception interceptor is built based on the global error handling mechanism Vue.config.errorHandler of the Vue.js framework, and the exception data it captures includes at least: error message, component unique identifier, the unique identifier of the form to which it belongs, and the current configuration properties of the component.

[0013] Preferably, in step (1), the exception aspect is implemented based on the Spring Boot AOP mechanism, and the captured exception data includes at least: exception type, method signature that throws the exception, request parameters, and distributed tracing ID.

[0014] Preferably, in step (2), the node types of the knowledge graph include: forms, pages, UI components, data models, API interfaces, and business rules; the relationship types of the knowledge graph include: inclusion, data binding, invocation, verification, and association.

[0015] Preferably, the knowledge graph reasoning module locates the erroneous component in the knowledge graph based on the unique form identifier and component identifier in the abnormal data, traces the API interface or data model that its data depends on along the relation edges, and outputs a root cause description by comparing the difference between the expected structure and the actual structure.

[0016] Preferably, in step (2), the deep learning classification model is a pre-trained TextCNN or BERT model.

[0017] Preferably, in step (3), the rule template library contains multiple predefined repair rules. Each rule includes matching conditions set based on error category and error message regular expressions, as well as a repair action to call the low-code platform management API to update metadata configuration.

[0018] Preferably, in step (3), the code generation model is a model obtained by fine-tuning a large language model, and its training data includes configuration fragments of low-code platforms, DSL examples, and platform-specific API call methods.

[0019] Preferably, after step (3), the method further includes step (4): automatically triggering the application verification process to confirm whether the anomaly has been resolved, and recording the root cause analysis process and repair results of this anomaly to the knowledge base for optimizing the deep learning classification model and the knowledge graph.

[0020] Preferably, the self-healing engine performs the repair by calling the management API of the low-code platform to update the form configuration content stored in the database, thereby completing the repair.

[0021] This AI-assisted anomaly detection and self-repair device for low-code platforms is characterized by the following features: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the AI-assisted anomaly detection and self-repair method for low-code platforms described above.

[0022] The main feature of this AI-assisted anomaly detection and self-repair processor for low-code platforms is that the processor is configured to execute computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the AI-assisted anomaly detection and self-repair method for low-code platforms described above are implemented.

[0023] The computer-readable storage medium is characterized in that it stores a computer program that can be executed by a processor to implement the steps of the AI-assisted anomaly detection and self-repair method for low-code platforms described above.

[0024] The AI-assisted anomaly detection and self-repair method, apparatus, processor, and computer-readable storage medium for low-code platforms of this invention have the following significant advantages over the prior art: Significant improvement in the accuracy and speed of anomaly root cause localization: In simulation tests, for 100 typical low-code configuration anomalies (such as data binding errors, API path changes, component property validation failures, etc.), the average root cause localization accuracy of the present invention reached 98%, and the average localization time was less than 3 seconds. The effectiveness and automation rate of the repair solutions are greatly improved: For the above-mentioned anomalies that can be automatically repaired, the repair solutions generated by this invention based on knowledge graphs and targeted rule / code generation models achieve a one-time success rate of 95%. Substantial reduction in operation and maintenance manpower costs: In the scenarios supported by this invention, it is expected to reduce manual troubleshooting and repair work for simple configuration anomalies by more than 85%, allowing operation and maintenance personnel to focus on more complex business logic issues; A qualitative leap in system stability: Through closed-loop automatic repair, the mean time to repair (MTTR) of low-code applications is reduced from hours to minutes or even seconds, significantly improving business continuity. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall architecture of the AI-assisted anomaly detection and self-repair method for low-code platforms according to the present invention.

[0026] Figure 2 This is a schematic diagram of the anomaly monitoring and intelligent analysis process of the present invention.

[0027] Figure 3 This is a schematic diagram illustrating the workflow of the self-healing engine of the present invention. Detailed Implementation

[0028] To more clearly describe the technical content of the present invention, the following description is provided in conjunction with specific embodiments.

[0029] Before describing the embodiments of the present invention in detail, it should be noted that, in the following, the terms “comprising,” “including,” or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0030] like Figure 1 As shown, the overall architecture of this invention includes three core engines: an anomaly detection engine, an AI analysis engine, and a self-repair engine.

[0031] I. Anomaly Detection Engine: Deep Context Capture for Low-Code "Configuration State" and "Runtime State" The exception monitoring engine is responsible for real-time monitoring and data collection of the full-stack runtime state of applications generated by the low-code platform, forming the foundation of the entire system's perception capabilities. This engine consists of exception interceptors deployed on the front end and exception aspects deployed on the back end. The front-end exception interceptors are built based on the Vue2 framework's global error handling mechanism (Vue.config.errorHandler), and their core functionality lies in capturing JavaScript runtime errors, Promise rejection exceptions, and Vue component rendering errors occurring in the browser environment.

[0032] All data collected by this engine is serialized into standard JSON format and reported to the backend service via asynchronous HTTP requests.

[0033] The core code for overriding the global error handling method to intercept exceptions is as follows: Vue.config.errorHandler = (err, vm, info) =>{ const contextData = { errorMessage: err.message, componentName: vm?. options?.name, formId: vm? root? options?.formId, dataState: JSON.stringify(vm?. data) }; navigator.sendBeacon(' / api / error-report', contextData); }; The backend exception aspect is implemented based on Spring Boot AOP. Its core function is to intercept and handle business and system exceptions thrown during all Controller layer interface calls in a microservice architecture. This aspect captures detailed information for each exception, including the exception type, exception message, method signature that threw the exception, HTTP parameters of the current request, and request body content, and associates it with a distributed trace ID (TraceID). The captured exception data is also standardized and sent to the central processing unit via an internal message queue. Through front-end and back-end collaboration, the exception monitoring engine achieves unified and standardized collection and reporting of full-stack exceptions in low-code applications.

[0034] In the backend Spring Boot service, the core code for unified exception handling using AOP aspects is as follows: @Around("execution( com..lowcode.. Controller. (..))") public Object handleController(ProceedingJoinPoint joinPoint) { try { return joinPoint.proceed(); } catch (Exception e) { ErrorReport report = new ErrorReport(); report.setExceptionMsg(e.getMessage()); report.setRequestParams(getRequestParams()); report.setServiceName("customer-service"); kafkaTemplate.send("error-topic", report); } } Compared to conventional solutions, front-end exception interceptors not only capture error stack traces, but more importantly, they proactively acquire and record the unique identifier (componentId) of the visual component that caused the exception, the unique identifier (formId) of the form or page to which the component belongs, and all of the component's current configuration properties (props). For example, when a data table component throws an error due to a sorting configuration error, the reported information will include {componentId: 'data-grid-01', formId: 'sales-report', erroneousProp: 'sortField', currentValue: 'unexistField'}.

[0035] This deep context capture lays the foundation for the subsequent AI engine to directly locate anomalies to specific configuration items.

[0036] II. AI Analysis Engine: Precise Root Cause Reasoning Based on Low-Code Domain Knowledge Graph The AI ​​analysis engine is the intelligent hub of the system, responsible for receiving, processing, and deeply analyzing abnormal data. It consists of a feature engineering module, a deep learning classification model, and a knowledge graph reasoning module. For example... Figure 2 As shown, its workflow is as follows: The feature engineering module receives raw anomaly data from the anomaly detection engine. Its core function is to transform unstructured anomaly log text into structured feature vectors. This module cleans, segments, and extracts key information from error messages and stack traces (such as using regular expressions to match specific error patterns, API paths, or database table names), and uses TF-IDF or word embedding techniques to quantify the text features. Finally, it concatenates these features into a complete feature vector, preparing it for model inference.

[0037] Deep learning classification models are built upon pre-trained TextCNN or BERT models, and their core function is to intelligently classify anomalies. These models are trained using a large amount of historical anomaly data and its corresponding manually labeled categories, learning to recognize different types of anomaly patterns. During processing, the model receives feature vectors as input and outputs one or more classification labels and confidence scores, such as classifying anomalies into specific categories like "front-end - null pointer access," "back-end - database record not found," or "microservice call timeout."

[0038] The knowledge graph reasoning module is the core of root cause analysis. Internally, it maintains a knowledge graph that characterizes the low-code platform's meta-model. The nodes of this graph include entities such as forms, components, API interfaces, and data models, and describe the relationships between these entities, including bindings, calls, and mappings. The reasoning module is activated after the classification model outputs results. For example, for a front-end exception classified as "API response data mismatch," this module locates the erroneous component in the knowledge graph based on the formId and component name in the exception. It then finds the API node that was called by following the edge "component bound to API," compares the expected response structure of that API with the actual structure, and ultimately pinpoints the root cause to either "the API returned JSON is missing the 'user.name' field" or "the component's configured data binding path 'data.user.name' is incorrect."

[0039] The specific construction content of knowledge graphs includes: Node types include: Form, Page, UI component, Entity, API, Business rule, etc.

[0040] Relationship types include contain, binds to, invokes, validates, and references. For example, component C - [bindsTo] -> field F of entity E; form S - [invokes] -> API A.

[0041] Taking the "Employee Information Management" case as an example, after the exception "TypeError: Cannot read property 'list' of undefined" is categorized, the knowledge graph reasoning module performs the following irreplaceable and precise positioning: Locate the erroneous component: Based on the formId and componentName in the exception, locate the erroneous dropdown selection component in the graph.

[0042] Tracing data dependencies: Along the bindsTo relationship edge, find the data source configured for this component, namely the API node / api / employees / titles.

[0043] Comparative analysis: Obtain the expected response structure defined by the API node (such as the OpenAPI specification) and compare it with the actual data path accessed in the exception information.

[0044] Output root cause: The exact output root cause is "The actual response structure (result.items) of API ' / api / employees / titles' does not match the expected data binding path (data.list) configured for the component 'dropdown selection component'".

[0045] III. Self-Healing Engine: Targeted code / rule generation for low-code DSLs and configuration models. like Figure 3 As shown, the self-healing engine is the system's execution terminal, responsible for receiving instructions from the AI ​​analysis engine and implementing automated repairs. It generates repair solutions through two strategies: a rule template library and a code generation model. The rule template library provides a series of predefined repair rules, whose core function is to handle simple exceptions with fixed patterns and high reproducibility. Each rule consists of matching conditions (such as error category and error message regular expression) and a repair action. For example, a rule can be defined as: when a "front-end - null pointer exception" is matched and the error message matches "Cannot read property 'X' of null / undefined", then the action "Add a null-safe operator outside the corresponding expression '{{X}}' in the component template, changing it to '{{X || ''}}'" is executed. The engine completes the repair by calling the low-code platform's management API to query and update the form configuration content (i.e., the content field) stored in the database.

[0046] The repair execution module implements the repair through the low-end platform API. The core code is as follows: public void executeRepair(String formId, RepairPatch patch) { lowcodeClient.updateFormContent(formId, patch.getContent()); } The code generation model handles complex exceptions that cannot be covered by the rule base. Its core function is to dynamically generate fix code based on context. This model is fine-tuned based on a large language model (such as CodeGPT). During processing, the model uses the detailed root cause description output by the AI ​​analysis engine (e.g., "Component Y throws an error because API Z returns data with excessively deep nesting") as natural language prompts to generate corresponding fix code snippets. For example, it generates a Vue computed property function to flatten the API return data before rendering. After the generated code undergoes security verification, the engine inserts it into the application as a fix script or directly updates the source code. After the fix is ​​implemented, the engine triggers an automated verification process to confirm whether the exception has been resolved and stores the entire fix process in a knowledge base for optimizing the AI ​​model.

[0047] The rule template library is specifically designed for high-frequency exception scenarios on low-code platforms. For example, the rule for "incorrect data binding path" doesn't generate native JavaScript code; instead, it generates an instruction to update the low-code platform's metadata database, directly correcting the component's `dataBinding.path` property value (e.g., changing it from `data.list` to `result.items`). This correction is done at the configuration layer, not the code layer, making it safer and more efficient.

[0048] Specialized optimizations for code generation models: Code generation models for complex fixes (such as CodeGPT) are trained not only with code in general programming languages ​​(such as JavaScript), but also with a large amount of configuration snippets, DSL examples, and platform-specific API calls from low-code platforms. This makes the generated code / configuration patches more compliant with the specifications and constraints of low-code platforms.

[0049] Example: When null protection needs to be added to a component, the model will not generate a generic if-else statement, but may instead generate a computed property configuration snippet suitable for that low-code platform, or directly modify the default value of the component property. This generation capability is not common knowledge, but is based on a deep understanding of the specific low-code platform architecture.

[0050] Based on the above technical content, in practical applications, the following alternative solutions can also be selected: AI model alternatives: If computing resources are limited, the deep learning model in the AI ​​analysis engine can be replaced by an ensemble learning model (such as gradient boosting tree XGBoost) combined with carefully designed feature engineering. Although the semantic understanding ability is slightly weaker, it can still achieve good results for anomaly classification with obvious patterns.

[0051] Simplified Knowledge Graph Solution: For small and medium-sized platforms, the construction of a knowledge graph can be simplified to a complex query relationship mapping based on Elasticsearch.

[0052] Alternative remediation strategy: A "manual review" step can be introduced. After the self-remediation engine generates a remediation plan, it is not executed immediately, but instead sent to the administrator for approval. The plan is then released only after the administrator's confirmation. This is suitable for scenarios with extremely high stability requirements and where remediation must be approached with caution.

[0053] To enable those skilled in the art to better understand the technical solution of the present invention, the implementation process of the present invention is described in detail below with reference to a specific low-code platform application development example.

[0054] In a specific embodiment of the present invention, this embodiment takes a typical anomaly that occurred in an "employee information management system" developed by an enterprise using a low-code platform as an example to demonstrate the complete process of the present invention from anomaly monitoring, intelligent analysis to automatic repair.

[0055] Implementation Scenario Background: A company developed an "Employee Information Management" form application using a low-code platform. The form's front-end is implemented using Vue2 components, including a dropdown selection component for employee titles. This component retrieves data by calling the backend Spring Boot microservice's ` / api / employees / titles` interface. The JSON data structure returned by the backend interface is: `{ "data": { "list": [ {"id": 1, "title": "Senior Engineer", "code": "senior-engineer"} ]}}`, while the data binding path configured in the front-end dropdown selection component is `data.list`. The specific implementation steps are as follows: Step 1: Exception Triggering and Capturing When a user accesses the employee information management form, the front-end page attempts to load the job level selection component. Due to a recent back-end API refactoring, the returned data structure has changed to { "result": { "items": [ {"id": 1, "title": "Senior Engineer", "code": "senior-engineer"} ]}}, causing a JavaScript runtime error when the component attempts to access data.list: "TypeError: Cannot read property 'list' of undefined". The Vue global error handler in the front-end exception monitoring engine immediately catches this exception and collects the following context information: { errorMessage: "TypeError: Cannot read property 'list' of undefined", stackTrace: "at DataTable.render(webpack-internal: / / / . / src / components / DataTable.vue:12:55)...", componentName: "select", formId: "emp_management_form_001", / / Unique form identifier assigned by the low-code platform dataState: JSON.stringify({...}) / / Current data state of the component } This information, after being serialized, is sent to the backend exception collection interface via an HTTP request. Simultaneously, because the backend interface returned an unexpected data structure, the Spring Boot service also logged related exceptions, which were captured by the backend exception monitoring aspect. { / / Exception information includes ExceptionType: "DataAccessException" ExceptionMessage: "Data format conversion exception" RequestParams: "{page: 1, size: 10}" ServiceName: "employee-service" TraceId: "trace-123456789" } Step Two: Anomaly Analysis and Root Cause Localization After receiving abnormal data reported by the front-end and back-end, the AI ​​analysis engine starts the analysis process: 1. Feature Extraction: The feature engineering module preprocesses error information.

[0056] features = { 'error_type': 'Frontend - Data Access Error' 'has_undefined_keyword': 1, 'component_type': 'DataTable', 'api_endpoint': ' / api / employees / titles', 'form_id': 'emp_management_form_001', 'data_path_attempted': 'data.list' # Extract from stack trace information } 2. Intelligent classification: Deep learning classifiers make predictions based on these features.

[0057] prediction = classifier.predict(features) # Output: # { # 'category': 'Front-end - Data structure mismatch', # 'confidence': 0.92 #} 3. Knowledge Graph Reasoning: The system queries the knowledge graph of the low-code platform.

[0058] / / Cypher query statement MATCH (form:Form {id:"emp_management_form_001"})-[:CONTAINS]->(comp:Component {name: "DataTable"}) MATCH (comp)-[binding:BINDS_TO]->(api:API {path: " / api / employees / titles"}) MATCH (api)-[expect:EXPECTS]->(schema:ResponseSchema) RETURN comp, api, binding.bindingPath as currentPath, schema.structure as expectedStructure The query results show that the component expects the data path to be data.list, while the response structure defined in the API documentation should be result.items.

[0059] Step 3: Generation and Execution of the Repair Solution The self-healing engine generates a repair plan based on the analysis results: 1. Rule matching: Matches the preset repair rules.

[0060] { "ruleId": "DATA_STRUCTURE_MISMATCH", "condition": "errorCategory == 'Frontend - Data Structure Mismatch' &&componentType == 'DataTable'", "action": { "type": "UPDATE_BINDING_PATH", "target": "forms[ {formId}].components[ {componentName}].dataBinding", "newPath": " {correctDataPath}" } } 2. Fix execution: Call the low-code platform management API to update component configuration.

[0061] { "operation": "updateComponentConfig", "componentId": "data_table_001", "updates": { "dataBinding": { "path": "result.items" / / Update data binding path } } } 3. Validation and Feedback: The system automatically triggers a form re-render to verify whether the exception has been resolved and stores the fix record in the knowledge base.

[0062] { "timestamp": "2023-11-08T14:30:00Z", "formId": "emp_management_form_001", "errorType": "Data structure mismatch", "rootCause": "API response structure change", "repairAction": "Update data binding path", "repairResult": "success", "confidenceScore": 0.92 } Through the implementation of this embodiment, the present invention demonstrates the following technical effects: 1. Full-stack monitoring capability: Simultaneously captures front-end and back-end anomalies and provides correlation analysis.

[0063] 2. Precise root cause identification: Accurately identify data binding path mismatch issues through knowledge graphs.

[0064] 3. Automated Repair: Automatically corrects component configurations without human intervention.

[0065] 4. Continuous learning: Repair experience is recorded in a knowledge base for use in optimizing future diagnostics and repairs.

[0066] To further verify the technical effects of the present invention, we designed the following comparative experiment: Experimental setup: Experimental group: Deploy the AI-assisted anomaly detection and self-repair method (integrating knowledge graph and targeted repair engine) for low-code platforms according to the present invention.

[0067] Control group: Deploy a simplified system based on an existing technology (CN202511293364.8) (using the same anomaly detection engine, but the AI ​​analysis module is a general-purpose large language model that has not been optimized for low-code domain knowledge, and the repair module only sends alarms and generalization suggestions).

[0068] Test cases: Construct 50 typical exception scenarios unique to the low-code platform, including front-end data binding errors, back-end API response structure changes, and business rule verification failures.

[0069] Evaluation metrics: root cause localization accuracy, localization time, and automated repair success rate.

[0070] Experimental results: Root cause localization: The experimental group accurately identified and precisely located the root causes of 49 anomalies (such as "the Y property of component X is misconfigured"), with an accuracy rate of 98%. The control group could only provide a general direction for 33 anomalies (such as "data access error"), with an accuracy rate of 66%, and could not associate them with specific configuration items.

[0071] Repair Results: The experimental group generated effective configuration updates or code patches for 48 automatically repairable anomalies and executed them successfully, achieving an automation repair success rate of 96%. The control group could not generate any directly executable repair solutions, only providing text suggestions, requiring complete manual repair.

[0072] Experimental conclusion: The technical solution of this invention, by introducing a deeply coupled low-code knowledge graph and a targeted repair generator, solves the core pain point of "inaccurate diagnosis and ineffective repair" when applying general AIOps solutions to low-code platforms. It has achieved unexpected technical effects in terms of accuracy and efficiency of exception handling and has significant technical innovation.

[0073] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0074] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution device.

[0075] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0076] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0077] In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "embodiment," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0078] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

[0079] In this specification, the invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and variations can be made without departing from the spirit and scope of the invention. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. An AI-assisted anomaly detection and self-repair method for low-code platforms, characterized in that, The method includes the following steps: (1) By deploying exception interceptors on the front end of the low-code application and exception aspects on the back end, full-stack exceptions generated during application runtime are captured in real time, and exception data containing low-code platform metamodel context information is collected. (2) The abnormal data is processed by the AI ​​analysis engine. The abnormal data is transformed into feature vectors through the feature engineering module. The abnormalities are classified by the deep learning classification model. The root cause of the abnormality is located by reasoning in combination with the pre-built low-code domain knowledge graph through the knowledge graph reasoning module. (3) Based on the obtained root cause localization results, a repair solution is generated by the self-repair engine; the self-repair engine matches predefined rules through the rule template library or dynamically generates repair code or configuration patches through the code generation model, and implements the repair.

2. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 1, characterized in that, In step (1), the exception interceptor is built based on the global error handling mechanism Vue.config.errorHandler of the Vue.js framework. The exception data it captures includes at least: error message, component unique identifier, the unique identifier of the form to which it belongs, and the current configuration property of the component.

3. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 1, characterized in that, In step (1), the exception aspect is implemented based on the Spring Boot AOP mechanism, and the captured exception data includes at least: exception type, method signature that throws the exception, request parameters, and distributed tracing ID.

4. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 2, characterized in that, In step (2), the node types of the knowledge graph include: forms, pages, UI components, data models, API interfaces, and business rules; the relationship types of the knowledge graph include: inclusion, data binding, invocation, verification, and association.

5. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 4, characterized in that, The knowledge graph reasoning module locates the erroneous component in the knowledge graph based on the unique form identifier and component identifier in the abnormal data, and traces the API interface or data model that its data depends on along the relation edges. By comparing the difference between the expected structure and the actual structure, it outputs a root cause description.

6. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 1, characterized in that, In step (2), the deep learning classification model is a pre-trained TextCNN or BERT model.

7. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 1, characterized in that, In step (3), the rule template library contains multiple predefined repair rules. Each rule includes matching conditions set based on error category and error message regular expressions, as well as a repair action to call the low-code platform management API to update metadata configuration.

8. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 1, characterized in that, In step (3), the code generation model is a model obtained by fine-tuning a large language model, and its training data includes configuration snippets of low-code platforms, DSL examples, and platform-specific API call methods.

9. The AI-assisted anomaly detection and self-repair method for low-code platforms according to any one of claims 1 to 8, characterized in that, After step (3), the method further includes step (4): automatically triggering the application verification process to confirm whether the anomaly has been resolved, and recording the root cause analysis process and repair results of this anomaly to the knowledge base for optimizing the deep learning classification model and the knowledge graph.

10. The AI-assisted anomaly detection and self-repair method for low-code platforms according to claim 1, characterized in that, The self-healing engine performs the repair by calling the management API of the low-code platform to update the form configuration content stored in the database, thereby completing the repair.

11. An AI-assisted anomaly detection and self-repair device for low-code platforms, characterized in that, The device includes: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the AI-assisted anomaly detection and self-repair method for low-code platforms as described in claim 9.

12. An AI-assisted anomaly detection and self-repair processor for low-code platforms, characterized in that, The processor is configured to execute computer-executable instructions, which, when executed by the processor, implement the steps of the AI-assisted anomaly detection and self-repair method for low-code platforms as described in claim 9.

13. A computer-readable storage medium, characterized in that, It stores a computer program that can be executed by a processor to implement the steps of the AI-assisted anomaly detection and self-repair method for low-code platforms as described in claim 9.

Images