Rule engine enhancement method, system and equipment based on large model and medium

Abstract

The invention relates to the technical field of rule engines, in particular to a rule engine enhancement method, system and device based on a large model and a medium, and the method comprises the following steps: receiving a natural language rule description input by a user, extracting condition elements and action elements in a rule through a pre-trained large language model, constructing a structured regular intermediate representation; converting the rule intermediate representation into a DSL rule supported by a target rule engine; grammar verification, logic consistency verification and compatibility verification with an MCP protocol are carried out on the DSL rule; in a DSL rule execution stage, calling a pre-registered external tool to match and execute a rule action, and collecting feedback data of action execution; contextual information in the rule execution process is maintained, the contextual information integrates device data, user input and feedback data, and rematching and execution of the rule are triggered based on change of the context state. And automatic debugging and operation of the rules are realized.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of rule engine, in particular to a rule engine enhancement method, system, device and medium based on a large model. BACKGROUND

[0002] As a core component of automated business logic, rule engine is widely used in Internet of Things, e-commerce risk control, smart home and other scenarios. However, the traditional rule engine always faces two core challenges in the application process. First, the maintenance of rules needs to be added by administrators, usually in graphical or script form. Although the graphical form is intuitive, it is limited by the expression form and it is difficult to realize complex business logic; while the script form can realize complex logic, but it requires high technical requirements for administrators, increasing the maintenance cost. Second, the execution of the traditional rule engine is heavily dependent on the pre-coded, hard-coded condition and action mapping relationship implemented by the developer. This means that any new business action needs to be written by the developer and embedded in the rule engine, which makes it difficult for the system to quickly respond to business changes and has poor scalability. The adjustment of business rules is no longer a simple configuration change, but needs to go through the complete process of development, testing and deployment, greatly limiting the agility of the business.

[0003] In recent years, the breakthrough progress of large language model (LLM) technology provides a new technical path for understanding and automatically generating structured rule representations through natural language. At the same time, model context protocol (MCP) as a new emerging standardized protocol provides a unified interaction framework for AI models and external tools (such as APIs, services), which can theoretically provide a dynamically expandable predefined action list for rule engines. This provides a new idea to solve these problems. Large models can understand complex business logic and convert it into structured rule representations. At the same time, model context protocol (MCP) as a standardized AI model and external tool interaction protocol can provide a predefined action list and execution feedback for rule engines.

[0004] However, how to effectively utilize large models to achieve full-automatic conversion, verification, execution and debugging from natural language rule description to executable DSL is still a technical problem to be solved. SUMMARY

[0005] To solve the above problems, the application provides a rule engine enhancement method, system, device and medium based on a large model.

[0006] In a first aspect, the application provides a rule engine enhancement method based on a large model, including the following steps: S1, receive the natural language rule description input by the user, perform semantic understanding and structural analysis through the pre-trained large language model, extract the condition elements and action elements in the rule, and construct a structured rule intermediate representation; S2, convert the rule intermediate representation into a DSL rule supported by the target rule engine, and perform syntax checking, logical consistency checking, and compatibility verification with the MCP protocol on the converted DSL rule; S3, after the DSL rule passes the verification, the rule engine loads the DSL rule; in the DSL rule execution phase, the pre-registered external tool is called through the MCP protocol to execute the rule action, and the feedback data of the action execution is collected in real time; S4, the state management module maintains the context information in the rule execution process, which integrates device data, user input, and feedback data of action execution in S3; the state management module triggers the re-matching and execution of the rule based on the change of the context state.

[0007] Through the state management module, the multi-party data (device, user, action feedback) is integrated and the execution context is dynamically updated, so that the rule engine can automatically trigger the re-matching and execution based on the latest system state. This not only realizes the automatic debugging and running of the rule, but also enables the entire system to intelligently respond to external changes, forming a closed loop of perception, decision-making, execution, and feedback.

[0008] As a further limitation of the technical solution of the present application, S1 includes the following steps: S11, combine the natural language rule description input by the user with the preset prompt template to generate a structured prompt, the prompt template being used to guide the large language model to identify entities, operators, logical relationships, and action instructions in the rule; S12, input the structured prompt into the pre-trained large language model to obtain the preliminary structured information output by the model; S13, analyze the preliminary structured information output by the model, extract the variables and operators in the condition part, and map the action part to the corresponding tool in the pre-registered tool list defined by the MCP protocol; S14, based on the results of analysis and mapping, generate a structured rule intermediate representation independent of the rule engine, which explicitly encapsulates the correspondence between the condition logic and the action call.

[0009] As a further limitation of the technical solution of the present application, the specific steps of generating the rule intermediate representation in S14 include: S141, constructing a conditional logic tree based on the parsed conditional elements, wherein leaf nodes are atomic conditional expressions containing variables and operators, and non-leaf nodes are logical operators connecting the atomic expressions; S142, encapsulating the mapped action elements as corresponding executable action objects, which at least contain the name of the MCP tool and a list of call parameters; S143, associating and binding the conditional logic tree with the executable action objects to form a complete rule structure, which is the rule intermediate representation; S144, serializing the rule structure into a standardized and transmissible data exchange format for transmission between different modules of the system.

[0010] By using the prompt template to guide model reasoning and performing step-by-step parsing and mapping, the conversion accuracy and reliability from natural language to structured information are ensured. The rule intermediate representation independent of the engine is generated, which provides a universal basis for subsequent flexible conversion to DSL of different target engines, and avoids binding with a specific engine.

[0011] As a further limitation of the technical solution of the application, the step of converting the rule intermediate representation into a DSL rule supported by the target rule engine in S2 includes: S21, according to the preconfigured mapping rule, converting the nodes of the conditional logic tree in the rule intermediate representation into DSL syntax elements supported by the target rule engine; wherein the logical operators are mapped into the logical keywords of the DSL, and the variables and operators are mapped into the expressions of the DSL; S22, generating action instructions for calling MCP tools in the target rule engine according to the executable action objects in the rule intermediate representation; the action instructions include tool calling statements and parameter passing logic; S23, assembling the converted conditional syntax elements and the action instructions according to the rule structure template of the target rule engine to generate a complete DSL rule text; S24, injecting the assembled rule content into the preconfigured DSL rule template and rendering to output the final DSL rule conforming to the syntax specification of the target rule engine.

[0012] By preconfigured mapping rules and templates for conversion, the configurability and high performance of the conversion process are realized, the DSL code conforming to the syntax specification of multiple target rule engines can be efficiently and accurately generated, and the adaptability of the scheme is enhanced.

[0013] As a further limitation of the technical solution of the application, the step of converting the DSL rule after conversion in S2 includes: S25, call the syntax checking interface provided by the target rule engine or use the compiler to parse the generated DSL rule, confirm that it meets the syntax specification of the target engine, and no compilation error is generated; S26, perform static analysis on the conditional logic of the rule to check whether there is a logical conflict; the logical conflict includes: a condition that is always true, a condition that is always false, and mutually contradictory rules; S27, traverse all action call statements in the DSL rule to verify whether the tool name and parameter structure called are consistent with the tool list metadata registered in the MCP server.

[0014] Through the triple verification of syntax, logic and MCP compatibility of the generated DSL rule, the correctness, safety and executability of the rule are ensured. This can automatically discover and exclude potential errors before deployment, greatly reducing the risk of system failure caused by rule errors, and improving the reliability and robustness of the system.

[0015] As a further limitation of the technical solution of the application, the step S3 comprises: S31, load the DSL rule file verified into the knowledge base of the target rule engine, and activate the rule to make it enter a state that can be matched by fact data; S32, the rule engine matches the fact data in its working memory with the rule condition, and when the matching is successful, generates an execution agenda containing action information to be executed; S33, for the action in the execution agenda, the rule engine calls an integrated MCP client to construct a call request conforming to the MCP specification, which includes a target tool identifier and a parameter list; S34, send the call request to the MCP server through the MCP client, and receive the tool call result returned by the MCP server, and return the result as feedback data of this action execution to the rule engine.

[0016] By integrating the custom processing mechanism with the MCP client, seamless communication between the rule engine and external tools is realized. This design non-invasively enhances the execution capability of the rule engine, enabling it to utilize a rich MCP tool ecosystem while ensuring the standardization and reliability of the execution process.

[0017] As a further limitation of the technical solution of the application, the step S4 comprises: S41, receive asynchronous data messages uploaded by Internet of Things device sensors, request data submitted by user interaction interfaces, and feedback data from MCP tool calls; S42, parse, clean and format convert the received heterogeneous data through a data adapter, and encapsulate it into standardized fact objects recognizable by the rule engine; S43, inserting or updating the packaged fact object into the working memory of the rule engine through the fact injector, so as to dynamically refresh the rule execution context state; S44, monitoring the insertion, update or deletion event of the fact object in the working memory through the event listener, and triggering the rule engine to perform full or incremental re-matching and execution when the change event is monitored.

[0018] Through the cooperative work of the data adapter, the fact injector and the event listener, unified and standardized management and real-time response to multi-source heterogeneous data are realized. This provides accurate and timely context information for the rule engine, and is the core of triggering intelligent linkage and closed-loop automation.

[0019] In a second aspect, the technical scheme of the present application provides a system for implementing the rule engine enhancement method based on a large model of the first aspect, comprising: A natural language processing module is configured to receive a natural language rule description input by a user, perform semantic understanding and structured analysis through a pre-trained large language model, extract condition elements and action elements in the rule, and construct a structured rule intermediate representation. A rule generation and verification module is configured to convert the rule intermediate representation into a DSL rule supported by a target rule engine, and perform syntax checking, logical consistency checking and compatibility verification with the MCP protocol on the converted DSL rule. A rule execution and MCP integration module is configured to control the rule engine to load the DSL rule after the DSL rule passes the verification, and to call a pre-registered external tool to execute a rule action and obtain feedback data of the action execution through the MCP protocol in a rule execution stage. A state management module is configured to maintain context information in a rule execution process, wherein the context information integrates device data, user input and action execution feedback data from the rule execution and MCP integration module; and the state management module triggers re-matching and execution of the rule based on changes in the context state.

[0020] As a further limitation of the technical scheme of the present application, the natural language processing module comprises: A prompt construction submodule is configured to combine the natural language rule description input by the user with a preset prompt template to generate a structured prompt. A model inference submodule is configured to input the structured prompt into a pre-trained large language model and obtain preliminary structured information output by the model. An analysis and mapping submodule is configured to analyze the preliminary structured information output by the model, extract variables and operators in the condition part, and map the action part to a corresponding tool in a pre-registered tool list defined by the MCP protocol. An intermediate representation generation submodule is configured to generate a rule intermediate representation independent of the rule engine and structured based on the parsed and mapped results.

[0021] As a further limitation of the technical solution of the present application, the intermediate representation generation submodule comprises: A logical tree construction unit is configured to construct a conditional logical tree based on the parsed conditional elements; An action binding unit is configured to encapsulate the mapped action elements into corresponding executable action objects; A rule assembly unit is configured to associate and bind the conditional logical tree and the executable action objects to form a rule structure; A serialization unit is configured to serialize the rule structure into a standardized and transmissible data exchange format.

[0022] As a further limitation of the technical solution of the present application, the rule generation and verification module comprises: A DSL converter is configured to convert the rule intermediate representation into a DSL rule supported by the target rule engine according to a preconfigured mapping rule; A rule verifier is configured to perform syntax checking, logical consistency checking, and compatibility verification with the MCP protocol on the converted DSL rule.

[0023] As a further limitation of the technical solution of the present application, the rule execution and MCP integration module comprises: A rule loading unit is configured to load the verified DSL rule into the knowledge base of the rule engine and activate it; An MCP client is configured to construct an MCP call request and communicate with the MCP server to obtain the tool call result when the rule action is triggered.

[0024] As a further limitation of the technical solution of the present application, the state management module comprises: A data adapter is configured to receive heterogeneous data from the Internet of Things device, the user interface, and the MCP integration module, and convert it into a standardized fact object; A fact injector is configured to insert or update the standardized fact object into the working memory of the rule engine; An event listener is configured to listen to the change events of the working memory and trigger the re-matching and execution of the rule engine.

[0025] As a further limitation of the technical solution of the present application, the system further comprises: A visual monitoring module is configured to generate and present a visual dashboard of the rule execution link, the state timing diagram, and the system activity statistics based on the data of the state management module.

[0026] In a third aspect, the present application provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; the memory stores computer program instructions executable by the at least one processor, and the computer program instructions are executed by the at least one processor to enable the at least one processor to perform the method for enhancing a rule engine based on a large model according to the first aspect.

[0027] In a fourth aspect, the present application provides a non-transitory computer readable storage medium storing computer instructions, and the computer instructions enable the computer to perform the method for enhancing a rule engine based on a large model according to the first aspect.

[0028] As can be seen from the above technical solutions, the present application has the following advantages: the present application enables business personnel to directly participate in the creation and modification of rules in the most intuitive way, without the need to learn complex graphical interface operations or domain-specific languages (DSL). This completely breaks down the barrier between business and technology, greatly reduces the cost and time of rule maintenance, and improves business agility.

[0029] With the powerful semantic understanding ability of the large language model, the present application can accurately parse and express business rules containing multi-condition nesting and complex logical relationships, and ensure the logical integrity through the structured rule intermediate representation, overcoming the limitation of the limited expression ability of the traditional graphical method.

[0030] Through seamless integration with the model context protocol (MCP), the execution of rule actions is abstracted as a call to a pre-registered external tool. This enables any new business action to be implemented by registering an MCP tool, without the need for developers to re-code the rule engine, greatly enhancing the flexibility and scalability of the system and enabling a quick response to business changes. BRIEF DESCRIPTION OF DRAWINGS

[0031] In order to more clearly illustrate the technical solutions of the present application, the drawings required to be used in the description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0032] Figure 1 The flowchart of the method provided by the embodiment of the present application.

[0033] Figure 2 The block diagram of the system provided by the embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the application purposes, features and advantages of the present application more obvious and easy to understand, the technical solutions protected by the present application will be described clearly and completely below by using specific embodiments and drawings. Obviously, the embodiments described below are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work belong to the scope protected by the present application.

[0035] Unless otherwise defined, all technical and scientific terms used in the present application have the same meanings as commonly understood by those skilled in the art to which the present application belongs. The terms used in the specification of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application.

[0036] As shown in Figure 1 The embodiment of the present application provides a large model-based rule engine enhancement method, which comprises the following steps: S1, receiving a user input natural language rule description, performing semantic understanding and structural analysis on the pre-trained large language model, extracting condition elements and action elements in the rule, and constructing a structured rule intermediate representation; In the embodiment of the present application, S1 specifically comprises: S11, combining the user input natural language rule description with a preset prompt template to generate a structured prompt, the prompt template being used to guide the large language model to identify entities, operators, logical relationships and action instructions in the rule; The user input natural language (such as reminding when the refrigerator temperature is high) is combined with the preset prompt template (containing rule structure, condition keywords and action constraints) to form a more explicit analysis instruction (such as please identify: when [refrigerator temperature>X℃], execute [send reminder], wherein X is a specific numerical value, and the action needs to match the MCP tool list”). The function of the template is to anchor the analysis direction of the large model, avoiding the generation of irrelevant information.

[0037] S12, inputting the structured prompt into the pre-trained large language model to obtain the preliminary structured information output by the model; The structured prompt is input into the large model to obtain the preliminary result output by the model (such as condition: refrigerator temperature>8℃; action: send reminder). This step converts the natural language into a preliminary key-value pair format, laying a foundation for subsequent analysis.

[0038] S13, analyzing the preliminary structured information output by the model, extracting variables and operators in the condition part, and mapping the action part to the corresponding tool in the pre-registered tool list defined by the MCP protocol; The preliminary results are further broken down, such as extracting variables (refrigerator temperature), operators (>), and thresholds (8℃) from the refrigerator temperature > 8℃; at the same time, the reminder sending action is matched with the tool list pre-registered in the MCP protocol (e.g., mapped to message push tool ID: Tool_001) to ensure that the action can be called by subsequent MCP.

[0039] S14. Based on the results of parsing and mapping, generate a structured intermediate rule representation that is independent of the rule engine. This intermediate rule representation explicitly encapsulates the correspondence between condition logic and action invocation.

[0040] The prompt template is constructed using the Few-Shot Learning format, and its content includes: System role definition, used to set the large language model as a rule parsing expert; The output format definition requires the model to output results in a specified structured format; An example of parsing one or more natural language rules into structured information.

[0041] The parsed conditions (variables, operators, thresholds) and mapped actions (tool IDs, call parameters) are encapsulated into a structure independent of the rule engine (such as JSON format: {"condition":{"variable":"refrigerator temperature","operator":">","value":8},"action":{"toolId":"Tool_001","params":{"content":"temperature too high"}}}). This structure can be adapted to different rule engines, avoiding repeated conversions.

[0042] It should be further explained that the specific steps for generating the intermediate representation of the rule in S14 include: S141. Based on the parsed condition elements, construct a condition logic tree, where the leaf nodes are atomic condition expressions containing variables and operators, and the non-leaf nodes are logical operators connecting these atomic expressions. Rules combining multiple conditions (such as refrigerator temperature > 8℃ and humidity > 60%, or door left open for 5 minutes) are transformed into a tree structure. Leaf nodes represent individual atomic conditions (e.g., temperature > 8℃, humidity > 60%, door left open for 5 minutes), while non-leaf nodes represent logical operators (e.g., AND, OR). This tree structure intuitively reflects the logical priority between conditions, avoiding parsing confusion.

[0043] S142. Encapsulate the mapped action elements into corresponding executable action objects, which at least include the name of the MCP tool and a list of calling parameters; The mapped action elements (such as calling the message push tool) are encapsulated as standardized objects, at least containing the MCP tool name (such as MessagePushTool) and the calling parameter list (such as receiver: user A, message content: high refrigerator temperature), ensuring the completeness of the parameters when the tool is called.

[0044] S143, the conditional logic tree is associated with the executable action object to form a complete rule structure, which is the rule intermediate representation; The conditional logic tree is associated with the executable action object to form a complete rule structure (such as conditional logic tree: [temperature> 8℃ and humidity> 60%]→action object: [MessagePushTool, parameter: user A, high temperature]), which clearly indicates "what conditions are met to perform what actions".

[0045] S144, the rule structure is serialized into a standardized and transmissible data exchange format for transmission between different modules of the system. The rule structure is converted into a transmissible format such as JSON or XML, which facilitates transmission between different modules of the system (such as natural language processing module, rule generation module), and avoids data loss or parsing errors caused by inconsistent formats.

[0046] The rule structure is implemented in JSON or YAML format, and its data structure at least includes the following fields: rule_id: rule unique identifier; condition: used to store the serialized conditional logic tree; actions: an ordered list used to store one or more executable action objects; metadata: metadata, including rule description and creation time information.

[0047] Through the semantic understanding ability of the pre-trained large language model (such as GPT series, BERT, etc.), the condition elements (such as the temperature of the intelligent refrigerator being higher than 8℃ for 10 minutes) and the action elements (such as sending a cooling reminder, starting the cooling mode) in the rule are first identified, and then these elements are organized into a rule intermediate representation (similar to semi-structured data, independent of specific rule engines, and adaptable to different engines) according to the preset logic (such as condition-action correspondence).

[0048] S2, the rule intermediate representation is converted into a DSL rule supported by the target rule engine; and the converted DSL rule is subjected to syntax checking, logical consistency checking, and compatibility verification with the MCP protocol; In this step, the rule intermediate representation is converted into a DSL rule supported by the target rule engine, including: S21. According to the pre-configured mapping rules, the nodes of the conditional logic tree in the intermediate representation of the rule are converted into DSL syntax elements supported by the target rule engine; wherein, logical operators are mapped to logical keywords of DSL, and variables and operators are mapped to expressions of DSL. S22. Based on the executable action objects in the intermediate rule representation, generate action instructions for calling the MCP tool in the target rule engine; the action instructions include tool call statements and parameter passing logic. S23. Assemble the converted conditional syntax elements and action instructions according to the rule structure template of the target rule engine to generate a complete DSL rule text; S24. Inject the assembled rule content into the preset DSL rule template, render it, and output the final DSL rule that conforms to the target rule engine syntax specification.

[0049] It should be noted that the pre-configured mapping rules are stored in a configurable mapping table, which supports defining different syntax mapping rules for different target rule engines; the DSL rule template is a rule framework file containing placeholders for a specific target rule engine.

[0050] Furthermore, the steps for performing syntax verification, logical consistency verification, and compatibility verification with the MCP protocol on the converted DSL rules include: S25. Call the syntax checking interface provided by the target rule engine or use the compiler to parse the generated DSL rules to confirm that they conform to the syntax specifications of the target engine and that no compilation errors have occurred. S26. Perform static analysis on the conditional logic of the rules to check for logical conflicts; the logical conflicts include: conditions that are always true, conditions that are always false, and contradictory rules; Internal logical conflict: such as "Condition 1: Temperature > 8℃, Condition 2: Temperature < 5℃", the algorithm determines through logical operations that "Condition 1 and Condition 2" will always be false, and is marked as an internal conflict; External rule conflict: Compare the conditions of the current rule with those of existing rules. If the conditions are completely identical but the actions are opposite (e.g., rule 1's action is "start cooling" and rule 2's action is "stop cooling"), it is marked as an external conflict, and the conflict details are output.

[0051] S27. Traverse all action call statements in the DSL rules and verify whether the tool name and parameter structure called are consistent with the tool list metadata registered in the MCP server.

[0052] Tool registration verification: Query the tool registry of the MCP server to confirm whether the tool corresponding to the action in the DSL rule has been registered (e.g., whether "MessagePushTool" is in the registry). Parameter matching check: compare the preset parameters of the tool (such as "MessagePushTool" requires "recipient" and "content" parameters) with the parameter list in the rule action, check whether the parameters are missing and whether the types are matched (such as "recipient" requires a string type, avoid passing in numbers); Permission check: according to the operation permission level of the current business personnel (such as "ordinary user" can only call basic tools, and "administrator" can call control class tools), check whether it has permission to call the tool in the rule (such as "refrigerator refrigeration control tool" requires administrator permission, and ordinary user calling triggers insufficient permission), and generate a compatibility error report.

[0053] Here, the logical consistency check is implemented by converting the rule condition logic into a Boolean expression and performing satisfiability solving or symbolic execution; The MCP compatibility verification is completed by querying the tool discovery interface of the MCP server, obtaining the list of registered tools and their mode definitions, and performing mode matching with the action call statements in the rule.

[0054] S3, after the DSL rule is verified, the rule engine loads the DSL rule; in the DSL rule execution phase, the pre-registered external tool is called through the MCP protocol to execute the rule action, and the feedback data of the action execution is collected in real time; In the embodiment of the application, the step S3 comprises: S31, load the verified DSL rule file into the knowledge base of the target rule engine, and activate the rule to make it enter a state that can be matched by fact data; S32, the rule engine matches the fact data in its working memory with the rule condition, and when the matching is successful, an execution agenda containing to-be-executed action information is generated; S33, for the action in the execution agenda, the rule engine calls an integrated MCP client to construct a call request conforming to the MCP specification, which includes a target tool identifier and a parameter list; S34, send the call request to the MCP server through the MCP client, and receive the tool call result returned by the MCP server, and return the result as the feedback data of this action execution to the rule engine.

[0055] The integration of the rule engine and the MCP client in S33 is realized in the following way: A custom action processor is configured in the rule engine, and the processor is registered to process the action call pointing to the MCP tool; When the rule engine needs to execute an action, the custom action handler is triggered, responsible for converting the action information into an MCP invocation request, and initiating the invocation through the integrated MCP client.

[0056] The parameter list in the MCP invocation request is derived from the relevant fact data in the rule engine working memory when the rule execution is triggered.

[0057] S4, maintaining the context information in the rule execution process through the state management module, the context information integrates the device data, user input and the feedback data of the action execution in S3; the state management module triggers the re-matching and execution of the rule based on the change of the context state.

[0058] In the embodiment of the application, the step S4 comprises: S41, receiving the asynchronous data message uploaded by the Internet of Things device sensor, the request data submitted by the user interactive interface, and the feedback data from the MCP tool invocation; S42, parsing, cleaning and format converting the received heterogeneous data through the data adapter, and packaging into a standardized fact object recognizable by the rule engine; S43, inserting or updating the packaged fact object into the working memory of the rule engine through the fact injector, thereby dynamically refreshing the context state of the rule execution; S44, monitoring the insertion, update or deletion event of the fact object in the working memory through the event listener, and triggering the rule engine to perform full or incremental re-matching and execution when the change event is monitored.

[0059] It should be noted here that in S41, the data received from the Internet of Things device adopts a message queue subscription mechanism, and the data received from the user interface adopts an HTTP request processing mechanism; In S44, the event listener monitors the change by monitoring the working memory event bus provided by the rule engine.

[0060] The visual board comprises: Rule trigger traceability view: showing the rule sequence triggered by a specific state change and the final executed action; Real-time state dashboard: dynamically visualizing the current value of key device data and business indicators; Execution audit log: recording all rule matching events, MCP tool invocations and their results in chronological order.

[0061] In some embodiments, S44 is followed by: S45, continuously recording and aggregating the matching results of the rule engine, the action execution state and the historical change data of the context state; S46, based on the aggregated data, generate a visual dashboard containing rule execution link, state timing diagram and system activity statistics, and render and push to business personnel through Web interface.

[0062] It needs to be further explained that the specific steps of generating a visual dashboard in S46 include: S461, based on the aggregated rule matching and action execution logs, reconstruct the complete rule execution link view starting from a specific initial event by associating rule ID and execution timestamp; S462, sort and sample the specified key context state data by time dimension, generate time series data set that can be used to draw state timing diagram; S463, based on the predefined time window, count the number of triggers, success times and average execution time of each rule, calculate the rule activity and success rate indicators; S464, call the interface of the visualization library, respectively convert the rule execution link, time series data set and activity indicators into corresponding visualization chart components; S465, embed the chart components, legends and controls into a unified Web page template, assemble into an interactive visual dashboard, and publish the page through the Web server.

[0063] The interactive visual dashboard supports the following operations: Drill-down: allows users to click on any node in the rule execution link to view detailed fact data for this rule matching; Time range selection: allows users to customize the time range to dynamically refresh the state timing diagram and activity statistics; Rule start-stop: provides interface controls to allow business personnel to directly enable or disable specific rules.

[0064] As shown in Figure 2 The embodiment of the application provides a system for implementing the rule engine enhancement method based on large model described in the above embodiment, comprising: A natural language processing module for receiving user input natural language rule description, performing semantic understanding and structured analysis through a pre-trained large language model, extracting condition elements and action elements in the rule, and constructing a structured rule intermediate representation; A rule generation and verification module for converting the rule intermediate representation into a DSL rule supported by the target rule engine, and performing syntax checking, logical consistency checking and compatibility verification with MCP protocol on the converted DSL rule; a rule execution and MCP integration module, configured to control a rule engine to load the DSL rule after the DSL rule is verified, and invoke a pre-registered external tool to perform a rule action and obtain feedback data of the action execution in a rule execution stage through an MCP protocol; a state management module, configured to maintain context information in a rule execution process, the context information integrating device data, user input, and action execution feedback data from the rule execution and MCP integration module; the state management module triggers re-matching and execution of a rule based on a change in a context state.

[0065] In some embodiments, the natural language processing module comprises: a prompt construction submodule, configured to combine a natural language rule description input by a user with a preset prompt template to generate a structured prompt; a model inference submodule, configured to input the structured prompt into a pre-trained large language model and obtain preliminary structured information output by the model; a parsing and mapping submodule, configured to parse the preliminary structured information output by the model, extract variables and operators in a condition part, and map an action part to a corresponding tool in a pre-registered tool list defined by an MCP protocol; an intermediate representation generation submodule, configured to generate an independent rule intermediate representation based on a result of parsing and mapping.

[0066] In some embodiments, the intermediate representation generation submodule comprises: a logic tree construction unit, configured to construct a condition logic tree based on parsed condition elements; an action binding unit, configured to encapsulate the mapped action elements as corresponding executable action objects; a rule assembly unit, configured to associate and bind the condition logic tree and the executable action objects to form a rule structure; a serialization unit, configured to serialize the rule structure into a standardized and transmissible data exchange format.

[0067] In some embodiments, the rule generation and verification module comprises: a DSL converter, configured to convert the rule intermediate representation into a DSL rule supported by a target rule engine according to a preconfigured mapping rule; a rule verifier, configured to perform syntax checking, logic consistency checking, and compatibility verification with an MCP protocol on the converted DSL rule.

[0068] In some embodiments, the rule execution and MCP integration module comprises: a rule loading unit configured to load the validated DSL rules to the knowledge base of the rule engine and activate them; a MCP client configured to construct a MCP invocation request and communicate with a MCP server to obtain tool invocation results when a rule action is triggered.

[0069] In some embodiments, the state management module comprises: a data adapter configured to receive heterogeneous data from the IoT device, the user interface and the MCP integration module, and convert them into standardized fact objects; a fact injector configured to insert or update the standardized fact objects into the working memory of the rule engine; an event listener configured to listen to change events of the working memory and trigger re-matching and execution of the rule engine.

[0070] In some embodiments, the system further comprises: a visualization monitoring module configured to generate and present visual dashboards of rule execution links, state timing diagrams and system activity statistics based on data of the state management module.

[0071] The embodiment of the present application also provides an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus. The communication bus can be used for information transmission between the electronic device and the sensor. The processor can invoke a logical instruction in the memory to execute the following method: S1, receiving a natural language rule description input by a user, performing semantic understanding and structural analysis through a pre-trained large language model, extracting condition elements and action elements in the rule, and constructing a structured rule intermediate representation; S2, converting the rule intermediate representation into a DSL rule supported by a target rule engine; and performing syntax checking, logical consistency checking and compatibility verification with a MCP protocol on the converted DSL rule; S3, after the DSL rule passes the verification, the rule engine loads the DSL rule; in the DSL rule execution phase, an external tool registered in advance is invoked through the MCP protocol to execute a rule action, and feedback data of the action execution is collected in real time; S4, context information in a rule execution process is maintained through a state management module, the context information integrates device data, user input and feedback data of the action execution in S3; and the state management module triggers re-matching and execution of the rule based on changes of the context state.

[0072] In addition, the logic instructions in the above-mentioned memory can be implemented in the form of a software function unit and sold or used as an independent product, and can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0073] The embodiment of the present application provides a non-transitory computer readable storage medium, which stores computer instructions, and the computer instructions cause a computer to execute the method provided by the above-mentioned method embodiment, for example, comprising: S1, receiving a natural language rule description input by a user, performing semantic understanding and structural analysis by using a pre-trained large language model, extracting condition elements and action elements in the rule, and constructing a structured rule intermediate representation; S2, converting the rule intermediate representation into a DSL rule supported by a target rule engine; and performing syntax checking, logical consistency checking, and compatibility verification with the MCP protocol on the converted DSL rule; S3, after the DSL rule passes the verification, the rule engine loads the DSL rule; in the DSL rule execution phase, the pre-registered external tool is called to execute the rule action through the MCP protocol, and feedback data of the action execution is collected in real time; S4, context information in a rule execution process is maintained through a state management module, and the context information integrates device data, user input, and feedback data of the action execution in S3; and the state management module triggers re-matching and execution of the rule based on changes of the context state.

[0074] The above description of the disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined in the present application can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown in the present application, but will conform to the widest scope consistent with the principles and novel features disclosed in the present application.

Claims

1. A method for enhancing a rule engine based on a large model, characterized in that, Includes the following steps: S1. Receive the natural language rule description input by the user, perform semantic understanding and structured parsing through a pre-trained large language model, extract the conditional elements and action elements in the rule, and construct a structured intermediate representation of the rule. S2. Convert the intermediate representation of the rule into a DSL rule supported by the target rule engine; and perform syntax verification, logical consistency verification, and compatibility verification with the MCP protocol on the converted DSL rule. S3. After the DSL rule is verified, the rule engine loads the DSL rule; during the DSL rule execution phase, the pre-registered external tools are called through the MCP protocol to match and execute rule actions, and feedback data of action execution is collected in real time. S4. The context information during the rule execution process is maintained through the state management module. The context information integrates device data, user input, and feedback data of action execution in S3. The state management module triggers the rematching and execution of rules based on changes in the context state.

2. The rule engine enhancement method based on a large model according to claim 1, characterized in that, The steps in S1 include: S11. Combine the natural language rule description input by the user with the preset prompt template to generate a structured prompt. The prompt template is used to guide the large language model to recognize entities, operators, logical relationships and action instructions in the rules. S12. Input the structured prompts into the pre-trained large language model to obtain the preliminary structured information output by the model; S13. Parse the preliminary structured information of the model output, extract the variables and operators in the condition part, and map the action part to the corresponding tools in the pre-registered tool list defined by the MCP protocol. S14. Based on the results of parsing and mapping, generate a structured intermediate rule representation that is independent of the rule engine. This intermediate rule representation explicitly encapsulates the correspondence between condition logic and action invocation.

3. The rule engine enhancement method based on a large model according to claim 2, characterized in that, The specific steps for generating intermediate representations of rules in S14 include: S141. Based on the parsed condition elements, construct a condition logic tree, where the leaf nodes are atomic condition expressions containing variables and operators, and the non-leaf nodes are logical operators connecting these atomic expressions. S142. Encapsulate the mapped action elements into corresponding executable action objects, which at least include the name of the MCP tool and a list of calling parameters; S143. Associate and bind the conditional logic tree with the executable action object to form a complete rule structure, which is the intermediate representation of the rule. S144. Serialize the rule structure into a standardized, transmissible data exchange format for transmission between different modules of the system.

4. The rule engine enhancement method based on a large model according to claim 3, characterized in that, The steps in S2 to convert the intermediate representation of a rule into a DSL rule supported by the target rule engine include: S21. According to the pre-configured mapping rules, the nodes of the conditional logic tree in the intermediate representation of the rule are converted into DSL syntax elements supported by the target rule engine; wherein, logical operators are mapped to logical keywords of DSL, and variables and operators are mapped to expressions of DSL. S22. Based on the executable action objects in the intermediate rule representation, generate action instructions for calling the MCP tool in the target rule engine; the action instructions include tool call statements and parameter passing logic. S23. Assemble the converted conditional syntax elements and action instructions according to the rule structure template of the target rule engine to generate a complete DSL rule text; S24. Inject the assembled rule content into the preset DSL rule template, render it, and output the final DSL rule that conforms to the target rule engine syntax specification.

5. The rule engine enhancement method based on a large model according to claim 4, characterized in that, The steps in S2 to perform syntax verification, logical consistency verification, and compatibility verification with the MCP protocol on the converted DSL rules include: S25. Call the syntax checking interface provided by the target rule engine or use the compiler to parse the generated DSL rules to confirm that they conform to the syntax specifications of the target engine and that no compilation errors have occurred. S26. Perform static analysis on the conditional logic of the rules to check for logical conflicts; the logical conflicts include: conditions that are always true, conditions that are always false, and contradictory rules; S27. Traverse all action call statements in the DSL rules and verify whether the tool name and parameter structure called are consistent with the tool list metadata registered in the MCP server.

6. The rule engine enhancement method based on a large model according to claim 5, characterized in that, The steps in S3 include: S31. Load the verified DSL rule file into the knowledge base of the target rule engine and activate the rule so that it can be matched with factual data. S32. The rule engine matches the fact data in its working memory with the rule conditions. When the match is successful, it generates an execution agenda containing information about the actions to be executed. S33. For actions in the execution agenda, the rules engine calls an integrated MCP client to construct a call request that conforms to the MCP specification. This request includes the target tool identifier and a list of parameters. S34. Send the call request to the MCP server through the MCP client, and receive the tool call result returned by the MCP server. Return the result as feedback data for this action execution to the rule engine.

7. The rule engine enhancement method based on a large model according to claim 6, characterized in that, The steps in S4 include: S41. Receive asynchronous data packets uploaded by sensors of IoT devices, request data submitted by user interface, and feedback data called from MCP tool. S42. The received heterogeneous data is parsed, cleaned, and format-converted through a data adapter, and encapsulated into standardized fact objects that can be recognized by the rule engine. S43. The encapsulated fact object is inserted or updated into the working memory of the rule engine through the fact injector, thereby dynamically refreshing the rule execution context state. S44. Monitor the insertion, update, or deletion events of fact objects in the working memory through event listeners, and trigger the rule engine to perform full or incremental rematching and execution when a change event is detected.

8. A system for implementing the rule engine enhancement method based on a large model as described in any one of claims 1-7, characterized in that, include: The natural language processing module is used to receive natural language rule descriptions input by users, perform semantic understanding and structured parsing through a pre-trained large language model, extract conditional elements and action elements from the rules, and construct a structured intermediate representation of the rules. The rule generation and verification module is used to convert the intermediate representation of the rule into DSL rules supported by the target rule engine, and to perform syntax verification, logical consistency verification and compatibility verification with the MCP protocol on the converted DSL rules. The rule execution and MCP integration module is used to control the rule engine to load the DSL rule after the DSL rule is verified, and to call the pre-registered external tools to execute rule actions through the MCP protocol during the rule execution phase, and to obtain feedback data on the action execution. The state management module is used to maintain context information during rule execution. The context information integrates device data, user input, and action execution feedback data from the rule execution and MCP integration module. The state management module triggers rule re-matching and execution based on changes in the context state.

9. An electronic device, characterized in that, The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; the memory stores computer program instructions executable by the at least one processor, the computer program instructions being executed by the at least one processor to enable the at least one processor to perform the rule engine enhancement method based on a large model as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions that cause the computer to execute the large-model-based rule engine enhancement method as described in any one of claims 1 to 7.

Images