Method, device, equipment and product for constructing business rule based on natural language

Abstract

The invention relates to a method for constructing a business rule based on a natural language, and the method comprises the steps: receiving a natural language rule description, and generating a corresponding to-be-filled field based on a natural language analysis model and the natural language description; filling the to-be-filled field into a preset regular sentence pattern template to generate a structured regular sentence pattern text; according to the rule sentence pattern text, a condition expression and a result expression are generated, the condition expression represents a trigger condition of the rule, and the result expression represents business processing logic hit by the rule; and executing the condition expression and the result expression based on the pre-configured rule field set in the rule engine to output a business rule result. According to the method, by introducing a natural language analysis model, rule configuration gets rid of strict grammar limitation, and business personnel can also autonomously complete rule creation and adjustment, so that the technical threshold is remarkably reduced, and the business response speed is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and computer program product for constructing business rules based on natural language. Background Technology

[0002] As information systems continue to expand in scale, more and more business processes rely on rule engines for automated processing. Rule engines typically describe judgment conditions and calculation logic through a set of executable rules, offering significant advantages in rapidly adjusting business strategies and reducing system coupling. Consequently, they are widely used in scenarios such as strategy configuration, payroll calculation, and human resource management.

[0003] However, existing rule engines still rely heavily on technical personnel for rule writing, with rules typically depending on specific syntax structures or scripting languages. While these rules can be correctly parsed by the system, they are difficult for business users lacking technical backgrounds to understand and implement. In practice, business users cannot write or modify rules themselves; any adjustments require technical personnel to translate business requirements and regenerate the rules. This model not only leads to information loss and misunderstandings during communication but also restricts rule change cycles to the work schedules of technical personnel, thus reducing overall configuration efficiency. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, electronic device, and computer program product for constructing business rules based on natural language, used to solve at least one technical problem.

[0005] This application provides a method for constructing business rules based on natural language, comprising: receiving a natural language rule description; generating corresponding fields to be filled based on a natural language parsing model and the natural language description; filling the fields to be filled into a preset rule sentence template to generate structured rule sentence text; generating a conditional expression and a result expression based on the rule sentence text, wherein the conditional expression represents the triggering condition of the rule and the result expression represents the business processing logic hit by the rule; and executing the conditional expression and the result expression in a rule engine based on a pre-configured set of rule fields to output the business rule result.

[0006] The method described above, which generates corresponding fields to be filled based on a natural language parsing model and a natural language description, includes: performing semantic recognition on the natural language description based on the natural language parsing model to extract rule fields; generating corresponding fields to be filled based on the rule fields and prompt information; wherein, the rule fields include one or more of the following: field name, comparison relationship, and target value.

[0007] As described above, the method for constructing the prompt information includes: extracting field name and field type information from the data acquisition model, and generating prompt information by combining at least one example, wherein the example includes: natural language rules and the fields to be filled in their mappings.

[0008] The method described above further includes: determining whether the rule field is in the rule field set by comparing the field semantics; and outputting a verification prompt to the user when the rule field does not belong to the rule field set, wherein the verification prompt includes a mismatch field indication and a replacement field suggestion.

[0009] The method described above, which generates conditional expressions and result expressions based on the rule-based sentence text, includes: mapping the field names and comparison relationships in the rule-based sentence text to the corresponding field identifiers and operators in the rule field set and combining them into rule-based conditional units; combining multiple rule-based conditional units based on the logical connection relationships in the sentence text to form a conditional expression; and converting the business processing description in the sentence text into a result expression in response to a hit on the conditional expression.

[0010] As described above, the configuration method for the rule field set includes: defining a data acquisition model and a rule model based on annotations, and combining data objects in the data acquisition model and the rule model into a rule field set.

[0011] The method described above further includes: collecting raw data based on a first annotation in the data acquisition model and converting it into a corresponding data object, wherein the first annotation includes one or more of the following: data source type, data acquisition parameters, and field mapping relationship; determining multiple data acquisition models referenced in the rule model based on a second annotation in the rule model; and merging the data objects in the multiple data acquisition models based on the field association relationship between the multiple data acquisition models to form a rule field set.

[0012] According to another aspect of this application, an apparatus for constructing business rules based on natural language is proposed, comprising: a receiving module for receiving a natural language rule description and generating corresponding fields to be filled based on a natural language parsing model and the natural language description; a sentence text generation module for filling the fields to be filled into a preset rule sentence template to generate structured rule sentence text; an expression generation module for generating a conditional expression and a result expression based on the rule sentence text, wherein the conditional expression represents the triggering condition of the rule and the result expression represents the business processing logic hit by the rule; and a business rule output module for executing the conditional expression and the result expression in a rule engine based on a pre-configured set of rule fields to output the business rule result.

[0013] According to another aspect of this application, an electronic device is proposed, including a processor and a memory, wherein a set of computer program instructions is stored on the memory, and the method for constructing business rules based on natural language as described above is implemented when the processor executes the set of computer program instructions in the memory.

[0014] According to another aspect of this application, a computer program product is proposed, which includes a set of computer program instructions that, when executed by a processor, implement the method for constructing business rules based on natural language as described above.

[0015] This application introduces a natural language parsing model, enabling business users to directly describe business requirements in natural language. The model automatically converts these descriptions into fields to be filled in for rule construction, thus eliminating the reliance on strict syntax in traditional rule expressions. Through this mechanism, even users without programming skills can accurately create and adjust rules without the need for secondary translation by technical personnel. Consequently, the technical barrier to rule configuration is significantly reduced, the rule change process is smoother, and the responsiveness of the business system to changes in requirements is significantly improved. Attached Figure Description

[0016] The preferred embodiments of the present invention will now be described in further detail with reference to the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for constructing business rules based on natural language according to an embodiment of this application.

[0017] Figure 2 This is a flowchart of the method for generating fields to be filled in step S110.

[0018] Figure 3 This is a flowchart of the method for generating the expression in step S130.

[0019] Figure 4 This is an architecture diagram of a natural language-based business rule system according to an embodiment of this application.

[0020] Figure 5 This is a schematic diagram of an apparatus for constructing business rules based on natural language according to an embodiment of this application.

[0021] Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] In the following detailed description, reference can be made to the accompanying drawings, which form part of this application and illustrate specific embodiments of the present application. In the drawings, similar reference numerals describe substantially similar components in different figures. Specific embodiments of the present application are described in sufficient detail below to enable those skilled in the art to implement the technical solutions of the present application. It should be understood that other embodiments may also be utilized, or structural, logical, or electrical changes may be made to the embodiments of the present application.

[0024] To address the aforementioned issues, this application proposes a method for constructing business rules based on natural language. This method introduces a natural language parsing model (such as a large language model), enabling business personnel to directly describe business rules in natural language. The system then automatically transforms these rule texts into structured rule expressions that can be parsed by the rule engine. In this way, rule generation and adjustment no longer rely on technical personnel manually writing expressions; business personnel can complete the configuration within their own understanding, significantly lowering the barrier to entry for rule usage.

[0025] Before the method is executed, to facilitate the retrieval of underlying data, this application first performs unified adaptation on multiple data sources, integrating data from different sources and with varying structures into business objects that can directly participate in rule processing, providing a consistent data foundation for subsequent rule generation and execution. Simultaneously, this application constructs a business rule annotation system, enabling the system to automatically parse the data model and rule relationships based on annotations, thereby achieving the expansion and standardized management of underlying data access capabilities.

[0026] According to one embodiment of this application, a data source adaptation module provides a unified data foundation for rule generation and calculation. This module is used to obtain business data from multiple heterogeneous data sources and assemble the raw data into a business object with a unified structure through data transformation and mapping mechanisms, so that subsequent rule processing does not need to concern itself with the underlying data source and format differences.

[0027] The data source adaptation module supports various data source types, including but not limited to file systems, relational databases, NoSQL databases, and remote interfaces based on web services. Specifically: For file system data sources, this module supports multiple structured file formats such as XLSX, JSON, and XML. It reads file content using a built-in file parser, parses the structured data into in-memory object representations, and can convert file fields into attributes of business objects based on field mapping relationships.

[0028] For database data sources, the module can access relational databases via JDBC interfaces or ORM frameworks to execute predefined SQL queries to retrieve business data. After data extraction, the query results are mapped to in-memory objects according to the field definitions of the business objects for unified processing.

[0029] For web service data sources, the module retrieves remote business data by calling RESTful API services via HTTP / HTTPS protocols. The module has a built-in HTTP client that supports request parameter encapsulation, response body parsing, and exception handling, and can convert the call results into a standardized data structure to meet subsequent object assembly requirements.

[0030] To address the rigidity issues inherent in traditional hard-coded code, this application defines a data acquisition model and a rule model based on annotations. It combines data objects from these models into a set of rule fields, thereby enabling the flexible and efficient construction of a context environment for subsequent rule parsing. Specifically: The data acquisition model is primarily used to define the data source and preprocessing logic. Raw data is acquired based on the first annotation in the data acquisition model and converted into corresponding data objects. The first annotation includes, but is not limited to, the following configuration items: Data source type and data acquisition parameters: Specify whether the data is obtained from a database, RPC interface or third-party tool (such as SDK), and define the unique key or parameter required for the query.

[0031] Field mapping: The first annotation can automatically convert heterogeneous field names or formats in the original data source into the standard field format required by the regular expression. For example, it can map and convert the database field user_birth_date into the age field required by the expression.

[0032] Calculation logic specification: For certain fields that cannot be directly read and require preprocessing, the first annotation can also specify a specific calculation function. This function is executed during the data collection phase (e.g., calculating "gross basic salary" based on "attendance days" and "daily wage"), directly obtaining the calculation result, and converting the result into the corresponding data object attribute.

[0033] The rule model is primarily used to describe the business rules themselves and their required data dependencies. The second annotation in the rule model identifies the multiple data collection models referenced within it. For example, a "salary calculation rule model" might reference both an "employee basic information model" and an "attendance statistics model" through its second annotation.

[0034] The second annotation establishes a soft connection between rules and data, eliminating the need to hard-write data loading logic in the code.

[0035] During runtime or initialization, based on the field relationships between multiple data acquisition models, the data objects from these models are merged to form a set of rule fields. Specifically: First, the second annotation on the rule model is parsed to identify all associated data collection models; Secondly, based on the first annotation in the data acquisition model, data transformation and function calculation are performed to obtain standardized data objects; Furthermore, based on the field relationships between multiple data acquisition models, the scattered data objects are flattened and merged. Finally, all the merged key-value pairs are encapsulated to form a set of rule fields.

[0036] In this way, business personnel or developers only need to focus on the annotation configuration to complete the transformation of complex raw data into rule-usable data, which greatly reduces the complexity of the rule field preparation stage.

[0037] Figure 1 This is a flowchart illustrating a method for constructing business rules based on natural language according to an embodiment of this application. Figure 1 As shown, the method includes: S110, receives natural language rule descriptions, and generates corresponding fields to be filled based on the natural language parsing model and the natural language descriptions; S120, The field to be filled is filled into a preset rule sentence template to generate structured rule sentence text; S130, Generate a conditional expression and a result expression based on the rule sentence text, wherein the conditional expression represents the triggering condition of the rule, and the result expression represents the business processing logic that the rule hits; S140, In the rule engine, the conditional expression and the result expression are executed based on the pre-configured set of rule fields to output the business rule result.

[0038] In step S110, the system receives a natural language rule description input from the user, such as "If the product type is a package and the order amount is greater than 10,000, then the bonus is 5% of the order amount." This type of input is a natural expression from the business personnel and is not formatted.

[0039] Upon receiving natural language, the system invokes a natural language processing model to perform semantic recognition on the text. This application describes a natural language processing model. This model performs word segmentation, part-of-speech tagging, and dependency parsing on the input text to identify key entities and logical intent. The model automatically extracts the core elements used to construct rules, namely the fields to be filled, such as product type (package), comparison operator (greater than), threshold (1000), and result action (order amount × 5%).

[0040] This step significantly lowers the barrier to rule configuration. Traditional rule engines require operators to understand specific code syntax, while this step allows business users to describe requirements in plain language, eliminating the language barrier between technology and business and improving configuration efficiency.

[0041] In step S120, the main task is to convert non-standard language into a standard intermediate state. This is done by using a pre-set standardized rule sentence template (e.g., "If [A] [condition][B], then [C]"). The scattered fields extracted in step S110 are automatically filled into this template according to their logical positions, generating a clear and unambiguous text, which is then displayed to the user for confirmation.

[0042] By using a templated intermediate layer, the inherent ambiguity of natural language is eliminated. This visual structure allows business users to intuitively check whether their understanding of the system is correct, ensuring that the subsequently generated computer code is completely consistent with the business intent and avoiding the risk of logical errors caused by "black box" transformation.

[0043] Step S130 involves translating business logic into machine logic. This is achieved by parsing the structured text generated in step S120 and breaking it down into two independent parts: Conditional expression: Corresponds to the "if" part in the template, used to determine whether the rule is true. It converts Chinese operators (such as "contains") into operators supported by the underlying engine (such as == or contains).

[0044] Result expression: The corresponding "then" part in the template defines the specific calculation action.

[0045] By converting text into expressions, logical judgment and business execution are decoupled. Compared to traditional single scripts, this separation allows the rule engine to quickly filter out rules that "meet the conditions" and then accurately perform "result calculations," improving the system's execution efficiency and logical clarity.

[0046] In step S140, the rule engine reads the pre-configured set of rule fields and performs calculations on the user data. Based on a unified field definition and calculation model, the rule engine executes rule logic on different input data and produces business-meaning results consistent with the rule set name.

[0047] If the conditional expression is satisfied, the result expression is executed, and the calculation result is written to the output object. For example, "bonus = total Amount × 0.05" will calculate and return the bonus result.

[0048] According to one embodiment of this application, the rule engine can be Spring Expression Language (SpEL), which, as a core component of the Spring framework, is widely used for expression evaluation and dynamic logic processing. As a powerful yet lightweight expression language, SpEL supports dynamic querying and manipulation of the object graph at runtime. With its superior execution performance, rich expression syntax, and seamless integration with the Spring ecosystem, SpEL has become the preferred solution for handling dynamic configuration in Java applications.

[0049] This application introduces a natural language parsing model, allowing business requirements to be described in natural language and automatically converting the natural language into fields to be filled, thus breaking SpEL's dependence on strict syntax rules. This approach effectively lowers the technical barrier to rule configuration, enabling business personnel without programming skills to directly define and adjust rules, reducing reliance on technical personnel and significantly improving business response efficiency.

[0050] Figure 2 This is a flowchart of the method for generating the field to be populated in step S110. For example... Figure 2 As shown, the method includes: S111, Semantic recognition is performed on the natural language description based on a natural language parsing model to extract rule fields; S112, Generate the corresponding fields to be filled based on the rule fields and prompt information; The rule fields include one or more of the following: field name, comparison relationship, and target value.

[0051] In step S111, upon receiving the natural language description input by the user, a pre-trained natural language parsing model (e.g., a large language model based on the Transformer architecture) is invoked to perform word segmentation, dependency parsing, and entity recognition on the text. The parsing model can identify the core elements constituting the business rules, i.e., rule fields, from unstructured text. These rule fields typically include field names specifying the judgment objects, comparison relationships defining the logical judgment methods, and target values ​​for setting judgment thresholds. For example, when describing "if the product type is a package," the parsing model can identify "product type" as the field name, "is" as the comparison relationship, and "package" as the target value.

[0052] In step S112, the extracted semantics are translated into system-recognizable data by combining contextual information. This prompt information typically includes all legal metadata definitions for the current business scenario, such as pre-configured rule model names and their data attribute lists annotated with annotations. Inputting the rule fields initially extracted in step S111 and the prompt information into the model for matching and validation ensures that the extracted field names are accurately mapped to the underlying data model of the system. For example, the recognized colloquial term "product type" is mapped to a standard field code defined internally by the system. By combining the prompt information, invalid or non-existent field descriptions in natural language can be effectively filtered out, preventing the generation of fields that do not exist in the system due to model illusion, thereby generating accurate and legal fields to be filled, providing a reliable data foundation for subsequent rule sentence template filling.

[0053] The above method can not only effectively avoid ambiguity in natural language description, but also ensure that the generated fields to be filled are accurately mapped to the underlying data model of the system, thereby reducing the probability of introducing invalid fields due to model illusion and significantly improving the accuracy and reliability of subsequent rule construction.

[0054] According to one embodiment of this application, the method for constructing a prompt message includes: extracting field name and field type information from a data acquisition model, and generating a prompt message in combination with at least one example, wherein the example includes: natural language rules and the fields to be filled in their mappings.

[0055] In one embodiment of this application, in order for a natural language parsing model (such as a large language model) to accurately map natural language into rule fields recognizable within the system, it is necessary to construct prompt information containing specific context. The quality of the constructed prompt information directly determines the accuracy of the generated fields to be filled. Specifically, the construction process of the prompt information mainly includes the assembly of content in the following two dimensions: 1. Metadata extraction based on data acquisition model First, the system parses the data collection model referenced in the current business scenario. Combining the annotation definitions from the previous embodiments, the system identifies the rule models marked with `@Rule` and their associated `@RuleDataModel`. Through an annotation scanning mechanism, key metadata is extracted from the data collection model, mainly including: Field name information: Extract the business meaning name of the field (such as "Product Type" in the annotation @RuleDataCol(name="Product Type")) and its corresponding physical attribute name (such as pdtType). This tells the large model "what data is currently available".

[0056] Field type information: Extract the data type of the field (such as String, Date, Double, etc.). This helps the large model determine which logical operators the field supports (for example, the "Date" type supports "earlier / later", while the "String" type supports "contains / equals").

[0057] 2. Example-based demonstration guidance To ensure the natural language parsing model fully understands "how to perform the transformation," at least one example is required during the construction process. This example contains a standard pair of "natural language rule descriptions" and their correctly mapped "fields to be populated" structures. For example, the prompt message could include the following example: Example input: If the product type is a package and the effective date is after 2025; Example output: Field = [{Name: pdtType, Operation: ==, Value: 'Package'}, {Name: startdate, Operation: >=, Value: '2025-01-01'}]".

[0058] By combining the aforementioned field names / type information with the example, the final prompt message is generated and sent to the natural language parsing model. This construction method is equivalent to setting a strict "response range" and "response template" for the model, effectively reducing the generation of fields that do not exist in the system (illusion), and ensuring that the output fields to be filled meet the requirements of subsequent processing in terms of format.

[0059] In one embodiment of this application, in order to ensure that the subsequently generated conditional expressions and result expressions can be correctly recognized and executed by the rule engine, a field validity verification step is also required after generating the fields to be filled.

[0060] Specifically, the method determines whether a rule field extracted from natural language belongs to a pre-defined set of rule fields by comparing the semantics of the fields. This set of rule fields is a list (whitelist) of legal fields constructed based on the data acquisition model (such as a data model defined by the @RuleDataModel annotation) in the aforementioned embodiments.

[0061] In practical applications, user-input natural language descriptions may be ambiguous or use non-standard terminology (for example, "order placement time" mentioned in spoken language may correspond to "order creation date" in the system model). Therefore, simple string matching often fails to meet the requirements. This embodiment employs semantic comparison techniques (such as vector similarity calculation or the semantic understanding capabilities of large models) to calculate the semantic distance between the extracted rule fields and each standard field in the rule field set.

[0062] When a rule field does not belong to the rule field set, i.e., when a matching field cannot be found in the existing model, or when the semantic similarity is lower than a preset threshold, the field is deemed invalid. In this case, to guide the user in making corrections, the system will output a verification prompt message to the user. The verification prompt message specifically includes the following two parts: Mismatch field indication: Clearly inform the user which word or phrase in the natural language description cannot be recognized by the system (e.g., "Unrecognized field 'Customer Level'").

[0063] Replacement field suggestions: Based on semantic proximity, recommend one or more of the most likely standard fields for the user to choose from (e.g., "Do you mean 'membership type'?").

[0064] This interactive validation and error correction mechanism not only intercepts invalid configuration requests but also helps business personnel quickly align vague business concepts to precise model fields, ensuring that the final generated rule expressions are legal and executable.

[0065] Figure 3 This is a flowchart of the method for generating the expression in step S130. For example... Figure 3 As shown, the method includes: S131, map the field names and comparison relations in the rule sentence text to the corresponding field identifiers and operators in the rule field set and combine them into rule condition units; S132, Based on the logical connection relationship in the sentence text, combine multiple rule condition units to form a condition expression; S133, in response to a hit of the conditional expression, converts the business processing description in the sentence text into a result expression.

[0066] In step S131, the rule sentence text generated in step S120 is parsed. By querying the pre-defined mapping relationship (i.e., the annotation configuration in the data acquisition model), the "field name" from the business perspective is converted into the underlying "field identifier" (variable name), and the "comparison relationship" from natural language is converted into the "operator" of the programming language standard. For example, in the bonus calculation scenario, when the rule sentence text contains "[product.product type] [equals][package]", "product type" is mapped to the field identifier pdttype, and "equals" is mapped to the equality operator ==. These converted elements are combined with the target value to form an independent rule condition unit, i.e., pdttype == 'package'.

[0067] In step S132, when the rule statement contains multiple judgment dimensions, logical connectors (such as "and" and "or") in the text are identified, converted into logical operators (such as && and ||), and multiple rule condition units are concatenated. For example, if the rule statement also contains "[product.effective date] [greater than or equal to][2025-01-01]", and the connection between the two is "[and]", the aforementioned rule condition unit is combined with the new unit startdate>= '2025-01-01' to generate the final condition expression: pdttype == 'package'&&startdate>= '2025-01-01'.

[0068] In addition, when generating conditional expressions, the priority attribute set in the configuration is also read. Priority is represented by a numerical value; the smaller the number, the higher the priority. When the rule engine runs, it will prioritize evaluating conditional expressions with smaller priority values, thereby ensuring that high-priority business policies are hit and executed first.

[0069] In step S133, a "hit" is considered achieved when the rule engine evaluates the conditional expression as "True" at runtime. The part after "then" in the sentence text (i.e., the business processing description) is parsed and converted into a result expression. This conversion supports not only the return of static values ​​but also dynamic calculations. For example, the description "Bonus = #order.order amount# × 0.7" is converted into the executable calculation formula total Amount × 0.7. Finally, the calculated return value of this result expression is bound to the name of the rule model (@Rule) (such as "Bonus") as the final output of the business rule. In this way, the rule engine can directly return calculation results with clear business meaning (such as a specific bonus amount), rather than just simple Boolean values.

[0070] The aforementioned method effectively eliminates the syntactic gap between business descriptions and code implementation by precisely mapping natural language fields to underlying identifiers and operators, ensuring the accuracy of rule execution. Simultaneously, by combining logical connections and priority mechanisms, it supports the flexible construction and orderly execution of complex strategies. Furthermore, by generating dynamically calculated result expressions, a complete closed loop from logical judgment to specific business numerical output is achieved, greatly enhancing the business processing capabilities of the rule engine.

[0071] The implementation methods and advantages of the embodiments of this application have been described above through multiple examples. The specific processing procedures of the embodiments of this application are described in detail below with reference to specific examples.

[0072] Figure 4 This is an architecture diagram of a business rule system based on natural language, according to an embodiment of this application. Figure 4 As shown, the system architecture includes a basic component layer, a service layer, and an application layer. The modules communicate with each other through interface calls or data transmission to complete the entire process of rule generation and execution.

[0073] I. Basic Component Layer The basic component layer includes data sources (databases, CSV files, etc.), the SpEL engine, and Spring-AI components.

[0074] The system can retrieve business data from databases or file systems such as CSV. SpEL is used to execute conditional and result expressions, and Spring-AI is used to interact with the large language model. The large language model in this application can be a general-purpose large language model, such as DeepSeek, Wenxin Yiyan, Qianwen, or Wukong. This layer provides data support and model capabilities for the upper-layer modules and is not within the core scope of this invention, but it provides the basic operating environment for the overall process.

[0075] II. Service Layer The service layer includes a data acquisition model, a rule model, and a Prompt model, and mainly uses annotation mechanisms to extend the underlying capabilities.

[0076] (1) Define the data acquisition model (DataModel) through annotations. The `@RuleDataModel` and `@RuleDataCol` annotations are used to describe the data source type and field information, for example: @RuleDataModel(name="DataModelA", type="database", jdbc="", sql="") public Class DataModelA { @RuleDataCol(name="FieldA") ColA; } The above definition indicates that DataModelA corresponds to the database source, where SQL is used to query field A.

[0077] Similarly, a data model from CSV can be defined: @RuleDataModel(name="DataModelB", type="csv", path="") public Class DataModelB { @RuleDataCol(name="Field B") ColB; } The data acquisition module parses the data source parameters based on annotations and loads the raw data into model objects via JDBC or a file parser. This mechanism allows data from different data sources to be used under a unified structure, enhancing the system's data adaptability.

[0078] (2) Annotation-based assembly rule model (RuleModel) The service layer further utilizes the @Rule annotation to specify the rule set, describing the data model on which the rules depend and their relationships, for example: @Rule(name="ruleA") public Class RuleA { @RuleDataModel(name="DataModelA", primary) DataModelA @RuleDataModel(name="DataModelB", link="ColB", join="DataModelA.ColA") DataModelB; } In the example above: DataModelA is the primary model, which determines the granularity of the records after concatenation. DataModelB is concatenated with the main model through a field association (ColB = DataModelA.ColA).

[0079] During execution, the system automatically concatenates the two data models row by row to form a "virtual large table" (a set of rule fields) based on the annotations, which is used for rule generation and execution. The arrows in the attached diagram, "Data Acquisition Model → Rule Model," represent this data flow process.

[0080] A further example is the bonus rules: @RuleDataModel(name="Product", type="database", jdbc="", sql="") public Class Product { @RuleDataCol(name="Product Number") pdtCode; @RuleDataCol(name="Product Type") pdtType; @RuleDataCol(name="Product Name") pdtName; @RuleDataCol(name="Effective Date") startdate; } @RuleDataModel(name="Order", type="database", jdbc="", sql="") public Class Order { @RuleDataCol(name="order number") orderCode; @RuleDataCol(name="Product Number") pdtCode; @RuleDataCol(name="Order Amount") totalAmount; @RuleDataCol(name="Cost") costAmount; } @Rule(name="Bonus") public Class Bonus { @RuleDataModel(name="Order", primary) Order @RuleDataModel(name="Product", link="pdtCode", join="Order.pdtCode") Product } The system uses these annotations to concatenate Product and Order data, forming a set of fields accessible to the bonus rules. The rule model module in the attached diagram corresponds to this process.

[0081] (3) Prompt model: rule suggestion construction for large models The Prompt model is responsible for building prompt information based on the rule model and field model, and sending it to the large language model invoked by Spring-AI components.

[0082] Its main functions include: providing hints about the data model and field list referenced in @Rule; constructing examples to help large models understand the rule structure; and receiving users' natural language expressions and converting them into the field structure required to populate the rule template.

[0083] III. Application Layer The application layer includes basic operation pages and large model pages, which are the interfaces directly interacted with by business users. In this embodiment, the system provides business users with two rule construction methods, allowing them to choose different modes for configuration based on the complexity of the rules.

[0084] (1) Rule construction method based on visual rule filling template When the business rule structure is relatively simple and the number of conditions is limited, users can directly construct rules through the basic operation page. This page automatically generates a rule population template based on the field list provided by the data collection model and the rule model, as shown in the typical form below: If [business field] [condition] [input value] [and / or] Then [execute the operation] Priority: [Value] Business users can construct conditions by selecting "Business Field" and "Condition Operator" from the dropdown menu and entering the target value. When a rule field needs to be referenced, the user can enter "#" to trigger a field list suggestion, and the system will automatically complete the content after selection.

[0085] Example of a structured sentence after filling in the blanks: If [product.product category] equals [package] [and] If [Product.Effective Date] is greater than or equal to [2025 / 01 / 01] and [None], then... Therefore, the bonus = #order.order amount# × 0.7 (2) Rule construction method based on large model assistance When business rules are complex, contain numerous conditions, combinational logic, nested meanings, or lengthy descriptions, business users can input natural language rule descriptions through the large model page, for example: If the product type is a package and the effective date is after 2025, then the bonus is 70% of the order amount.

[0086] The Prompt model provides the large language model with: the current rule model (@Rule); the data collection model fields referenced (@RuleDataModel); example fields, example rules, and standard parsing format.

[0087] Under the constraints of this information, the large model performs structured parsing of natural language: extracting rule condition units such as field names, comparison relations, and target values; verifying whether the extracted fields belong to the field range of the rule model, and prompting the user if they do not match; converting the parsing results into a visual rule template structure; and proceeding to the expression generation stage after the user confirms that there are no errors.

[0088] With the assistance of large models, the system can automatically generate structured rule sentences, reducing the burden of manually filling in templates and lowering the risk of rule assembly errors.

[0089] After the rule engine executes the expression generated by the above rules, it does not directly return the raw calculation result to the upper-layer application. Instead, a result processing module performs in-depth processing on the execution result. This result processing module aims to ensure the security, standardization, and traceability of the output data. The specific processing flow is as follows: Result Verification: The system first verifies the rationality and validity of the raw results output by the rules engine. Because the underlying data source may contain dirty data (such as incorrectly entered negative costs or abnormally large amounts), directly outputting the calculation results could lead to serious business incidents. Therefore, the results are validated based on preset security thresholds or logical constraints.

[0090] For example, in the aforementioned "bonus calculation" scenario, if the bonus amount calculated by the SpEL expression is negative (possibly due to abnormal deduction logic), the result verification unit will identify the abnormality, intercept the output, and mark the calculation status as "abnormal" to prevent erroneous negative amounts from flowing into the payroll system.

[0091] Data formatting: After validation, the system converts the raw calculated values ​​into a standard format required for business display or interface interaction. The rules engine (SpEL) typically returns high-precision floating-point numbers or raw objects, while the business side often requires a specific display format.

[0092] For example: Amount Formatting: Converts the calculated result 700.0 to a currency format of 700.00 with two decimal places.

[0093] Percentage Conversion: If the rule calculates a commission rate (e.g., 0.7), the system will format it as a percentage string "70%" for direct display on the front-end page.

[0094] Business Encapsulation: To facilitate unified calls from upper-layer applications (such as payroll systems and CRM systems), the result processing module encapsulates validated and formatted data into a standard business response object. This object contains not only the calculation result data but also the status code, execution message, and rule metadata (such as the matched rule ID).

[0095] Through this standardized encapsulation, upper-layer applications do not need to care about the specific return type of the underlying rule engine. They only need to parse the unified response object to obtain the decision result, which reduces the coupling between systems.

[0096] Log recording: While completing the above processing, the system will automatically trigger the logging mechanism. This mechanism is responsible for persistently storing the entire chain of information related to rule execution, including: input parameter snapshots, rule identifiers that were hit, execution time, raw calculation results, and the final business output results.

[0097] Detailed log records provide traceable data support for subsequent business audits (such as financial audits) and problem investigations (such as why a certain employee's bonus was calculated incorrectly), thus achieving transparency in the rule enforcement process.

[0098] Corresponding to the method embodiments of this application, this application also provides an apparatus for constructing business rules based on natural language, such as... Figure 5 As shown, the business rules device includes: The receiving module 110 is used to receive natural language rule descriptions and generate corresponding fields to be filled based on the natural language parsing model and the natural language descriptions; The sentence text generation module 120 is used to fill the field to be filled into a preset rule sentence template to generate structured rule sentence text; The expression generation module 130 is used to generate conditional expressions and result expressions based on the rule sentence text. The conditional expressions represent the triggering conditions of the rule, and the result expressions represent the business processing logic that the rule hits. The business rule output module 140 is used to execute the conditional expression and result expression in the rule engine based on a pre-configured set of rule fields to output the business rule result.

[0099] Figure 6This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. The electronic device can be implemented as a server or other various terminal devices, such as desktop personal computers, tablet computers, laptop computers, mobile phones, etc., including a processor 601 and a memory 602. The memory 602 stores a program instruction set. When the processor 601 executes the program instruction set in the memory 602, it implements any of the aforementioned methods for constructing business rules based on natural language.

[0100] Specifically, the processor 601 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0101] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0102] The memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the method for constructing business rules based on natural language provided by this invention.

[0103] In one example, the electronic device may also include a communication interface 603 and a bus 604. The processor 601, memory 602, and communication interface 603 are connected via bus 604 and communicate with each other. Communication interface 603 is primarily used to enable communication between modules, devices, units, and / or equipment in the embodiments of the present invention. Bus 604 includes hardware, software, or both, coupling components of the online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) Interconnect, Industry Standard Architecture (ISA) bus, Infinite Bandwidth Interconnect, Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 604 may include one or more buses. Although specific buses are described and illustrated in the embodiments of the present invention, the present invention is contemplated by any suitable bus or interconnect.

[0104] The present invention also provides a computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, implement any of the methods for constructing business rules based on natural language in the foregoing embodiments. The computer-readable storage medium can be any medium that can tangibly contain or store computer-executable instructions for use by or in conjunction with an instruction execution system, apparatus, or device. The storage medium can be a transient computer-readable storage medium or a non-transitory computer-readable storage medium. Non-transitory computer-readable storage media may include, but are not limited to, magnetic storage devices, optical storage devices, and / or semiconductor storage devices. Examples of such storage devices include, for example, magnetic disks, optical discs based on CD, DVD, or Blu-ray technology, and persistent solid-state storage such as flash memory and solid-state drives.

[0105] This invention also provides a computer program product, comprising a set of computer program instructions, which, when executed by a processor, implement any of the methods for constructing business rules based on natural language in the foregoing embodiments. The computer program product includes, but is not limited to, application installation packages published on websites and app stores, application plugins, and mini-programs that can run within certain applications.

[0106] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0107] The above embodiments are for illustrative purposes only and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the scope of the invention. Therefore, all equivalent technical solutions should also fall within the scope of the invention.

Claims

1. A method of constructing business rules based on natural language, characterized by, The method comprises the following steps: receiving a natural language rule description, generating a corresponding to-be-filled field based on a natural language parsing model and the natural language description; filling the to-be-filled field into a preset rule sentence template to generate a structured rule sentence text; generating a condition expression and a result expression according to the rule sentence text, wherein the condition expression represents a triggering condition of a rule, and the result expression represents a business processing logic of rule hitting; executing the condition expression and the result expression in a rule engine based on a preconfigured rule field set to output a business rule result.

2. The method of claim 1, wherein, The method of generating a corresponding to-be-filled field based on a natural language parsing model and a natural language description comprises the following steps: performing semantic recognition on the natural language description based on the natural language parsing model to extract a rule field; generating a corresponding to-be-filled field based on the rule field and prompt information; wherein the rule field comprises one or more of a field name, a comparison relationship and a target value.

3. The method of claim 2, wherein, The method of constructing the prompt information comprises extracting field name and field type information from a data collection model, and generating prompt information in combination with at least one example, wherein the example comprises a natural language rule and a to-be-filled field mapped thereto.

4. The method of claim 2, wherein, The method further comprises the following steps: judging whether the rule field is in a rule field set through field semantic comparison, and outputting verification prompt information to a user in response to the rule field not belonging to the rule field set, wherein the verification information comprises a non-matching field indication and a replacement field suggestion.

5. The method of claim 1, wherein, The method of generating a condition expression and a result expression according to the rule sentence text comprises the following steps: mapping a field name and a comparison relationship in the rule sentence text into a corresponding field identifier and an operator in the rule field set respectively and combining them into a rule condition unit; combining multiple rule condition units to form a condition expression based on a logical connection relationship in the sentence text; in response to hitting the condition expression, converting a business processing description in the sentence text into a result expression.

6. The method of claim 1, wherein, The method of configuring the rule field set comprises defining a data collection model and a rule model based on an annotation, and combining data objects in the data collection model and the rule model into a rule field set.

7. The method of claim 6, wherein, The method further comprises the following steps: collecting original data based on a first annotation in the data collection model and converting the original data into corresponding data objects, wherein the first annotation comprises one or more of a data source type, a data acquisition parameter and a field mapping relationship; determining multiple data collection models referenced in the rule model based on a second annotation in the rule model; merging data objects in the multiple data collection models based on a field association relationship between the multiple data collection models, thereby forming a rule field set.

8. An apparatus for constructing business rules based on natural language, characterized in that, The method comprises the following steps: a receiving module configured to receive a natural language rule description, generate a corresponding to-be-filled field based on a natural language parsing model and the natural language description; a sentence text generation module configured to fill the to-be-filled field into a preset rule sentence template to generate a structured rule sentence text; An expression generating module configured to generate a condition expression and a result expression according to the rule sentence text, the condition expression representing a triggering condition of the rule, and the result expression representing a business processing logic of the rule; A business rule output module configured to execute the condition expression and the result expression based on a preconfigured rule field set in a rule engine to output a business rule result.

9. An electronic device, comprising: A computer program product comprising a processor and a memory, the memory having stored thereon a set of computer program instructions which, when executed by the processor, implement the method of any one of claims 1-7.

10. A computer program product, characterised in that, A computer program product comprising a set of computer program instructions which, when executed by a processor, implement the method of any one of claims 1-7.

Images