An insurance rule migration method based on a large model and automation and related equipment

Abstract

The application relates to the technical field of insurance rule migration, and discloses an insurance rule migration method based on a large model and automation and related equipment, wherein a syntax analysis framework is used to perform lexical analysis and syntax analysis on source rule text to generate an abstract syntax tree, rule structure information is extracted and mapped to a template engine to generate intermediate rule text, a large model is used for semantic correction to generate target rule text, and finally, the target rule text is stored in a target rule engine after syntax checking, thereby solving the problems of a long time-consuming manual migration mode, huge labor and time costs, heavy burden on business personnel to learn a new syntax system, logical errors caused by manual conversion, rule errors exposed only at runtime due to the lack of real-time syntax checking, and difficulty in guaranteeing version consistency, achieving automatic and accurate migration of insurance rules, reducing migration costs and learning costs of business personnel, improving migration efficiency and rule accuracy, and guaranteeing technical self-controllability and stable operation of a core business system.

Description

Technical Field

[0001] This invention relates to the field of insurance rule migration technology, and in particular to an insurance rule migration method and related equipment based on a large model and automation. Background Technology

[0002] In the core business systems of industries such as insurance and finance, enterprises urgently need domestically produced engines for key automated decision-making processes such as underwriting and claims settlement to ensure technological independence and controllability.

[0003] Currently, the industry generally adopts a manual migration method, where business personnel read the original rule base logic line by line and then rewrite and enter it according to the target engine's syntax specifications. However, the existing technology has the following objective drawbacks: First, manually converting tens of thousands of rules takes several months or more, resulting in huge manpower and time costs; second, after migrating to the new platform, business personnel are forced to learn a completely new syntax system, completely abandoning their original Ilog writing habits, resulting in high learning costs and difficulties in later maintenance; third, there are significant differences between the syntax specifications of Ilog and domestic engines, making it difficult for manual conversion to accurately adapt and easily leading to logical errors; in addition, the manual migration process lacks real-time syntax checking, and rule errors are often only discovered at runtime, posing risks to core business; finally, the migration cycle is long, the source rules change dynamically, and it is difficult to update them manually in sync, making it difficult to guarantee version consistency.

[0004] Therefore, there is an urgent need to provide a technical solution to address the above problems. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method and related equipment for insurance rule migration based on a large model and automation.

[0006] Firstly, this invention provides a method for insurance rule migration based on a large model and automation. The technical solution of this method is as follows: Retrieve the source rule text written according to the syntax of the first rule engine; The source rule text is subjected to lexical and syntactic analysis using a syntax parsing framework to generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text. Traverse the abstract syntax tree to extract rule structure information, which includes conditional expressions, action statements, and variable definitions. The rule structure information is mapped to the template engine, which then generates intermediate rule text based on a preset transformation template. The intermediate rule text is input into the large model, and the large model performs semantic correction on the intermediate rule text to generate target rule text that conforms to the syntax of the second rule engine. The target rule text is subjected to syntax validation. After the validation passes, the application programming interface of the second rule engine is called to store the target rule text in the second rule engine.

[0007] The beneficial effects of the insurance rule migration method based on a large model and automation proposed in this invention are as follows: The method of this invention performs lexical and syntactic analysis on the source rule text using a syntax parsing framework to generate an abstract syntax tree. It then traverses and extracts rule structure information and maps it to a template engine to generate intermediate rule text. A large model then performs semantic correction to generate the target rule text. Finally, after syntactic verification, the text is stored in the target rule engine. This method solves the problems of time-consuming manual migration, huge manpower and time costs, heavy burden on business personnel to learn a completely new syntax system, easy logical errors due to manual conversion, lack of real-time syntax checking leading to the exposure of rule errors only at runtime, and difficulty in ensuring version consistency. It achieves automated and precise migration of insurance rules, reduces migration costs and business personnel learning costs, improves migration efficiency and rule accuracy, and ensures the technical autonomy, controllability, and stable operation of the core business system.

[0008] Based on the above scheme, the insurance rule migration method based on large model and automation of the present invention can be further improved as follows.

[0009] In one alternative approach, the step of obtaining the source rule text written according to the syntax of the first rule engine includes: Raw rule data is collected from the first rule engine platform; The original rule data is parsed to generate structured rule information; The terminology of the business objects in the structured rule information is converted according to the preset business object terminology mapping relationship; The source rule text, conforming to the syntax of the first rule engine, is constructed based on the structured rule information after terminology transformation.

[0010] The beneficial effects of adopting the above optional approach are as follows: by further collecting raw rule data from the first rule engine platform and performing parsing and terminology conversion, the problem of low quality of basic migration data caused by scattered source rule data and inconsistent business object terminology is solved, thereby improving the standardization of source rule text and the reliability of subsequent conversion.

[0011] In one alternative approach, the step of performing lexical and syntactic analysis on the source rule text using a syntax parsing framework to generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text includes: The built-in lexical analyzer of the syntax parsing framework is invoked to scan the source rule text and split the source rule text into a sequence of lexical units; The built-in parser of the syntax parsing framework is invoked to perform grammatical structure verification on the lexical unit sequence, and the abstract syntax tree reflecting the logical nesting relationship and operator precedence of the source rule text is constructed according to the predefined syntax rules; When the parser detects that the sequence of lexical units does not conform to the predefined grammar rules, it generates corresponding grammar error information.

[0012] The advantages of adopting the above optional approach are: further calling the built-in lexical analyzer and parser of the syntax parsing framework solves the problem of deviation in the construction of abstract syntax tree caused by the difficulty of accurately identifying lexical units and grammatical structures in manual parsing, and improves the integrity of the source rule text's logical structure and grammatical hierarchy.

[0013] In one alternative approach, the step of traversing the abstract syntax tree and extracting rule structure information includes: Visit each node in the abstract syntax tree according to the preset traversal order; Identify condition nodes, action nodes, and variable declaration nodes based on node type; Obtain the child nodes contained in the condition node and combine them into a condition expression; obtain the sequence of execution statements contained in the action node as an action statement; obtain the variable name and variable type defined in the variable declaration node as a variable definition. The conditional expression, the action statement, and the variable definition are combined into the rule structure information.

[0014] The beneficial effects of adopting the above optional method are as follows: further accessing the abstract syntax tree nodes according to the preset traversal order and identifying condition, action and variable declaration nodes solves the problem of incomplete extraction of rule structure information caused by disordered node traversal and type identification errors, and improves the accuracy of extracting condition expressions, action statements and variable definitions.

[0015] In one alternative approach, the step of mapping the rule structure information to a template engine, and having the template engine generate intermediate rule text based on a preset transformation template, includes: The corresponding conversion template is determined from the preset template library based on the engine type of the second rule engine; The conditional expression, action statement, and variable definition in the rule structure information are passed to the template engine as context variables. The template engine dynamically fills the context variables into the corresponding positions of the conversion template according to the template instructions defined in the conversion template, and outputs the filled conversion template as the intermediate rule text.

[0016] The advantages of adopting the above optional method are: further determining the conversion template from the template library according to the second rule engine type and dynamically populating the context variables, solving the problem of inconsistent intermediate rule text format caused by template selection errors and variable mapping misalignment, and improving the compatibility between intermediate rule text and target engine syntax.

[0017] In one alternative approach, the step of inputting the intermediate rule text into a large model, and semantically correcting the intermediate rule text using the large model to generate target rule text that conforms to the syntax of the second rule engine includes: The intermediate rule text is input into the large model, and the large model performs rule logic decomposition on the intermediate rule text to identify the predefined part, condition part and action part; Based on the preset business object terminology mapping relationship, semantic transformation is performed on the business objects in the predefined part, the condition part and the action part to eliminate the differences in business object expression between different rule engines; According to the preset conversion logic, the semantically converted predefined part, the condition part, and the action part are mapped to syntactic elements that conform to the syntax of the second rule engine. The mapped syntax elements are post-processed to correct abnormal statements in the text generated by the large model, and then combined to form the target rule text.

[0018] The beneficial effects of adopting the above optional approach are as follows: by further performing logical decomposition, semantic transformation and post-processing of intermediate rule text through large model, the problem of semantic deviation of target rule caused by differences in the expression of business objects between different engines and the residual of abnormal statements is solved, thereby improving the semantic accuracy and grammatical compliance of target rule text.

[0019] In one optional approach, the step of performing syntax validation on the target rule text, and then, after passing the validation, calling the application programming interface of the second rule engine to store the target rule text into the second rule engine, includes: Perform a syntactic integrity check on the target rule text to detect whether the target rule text contains missing or incomplete sentences. The target rule text is subjected to variable reference validity verification, and the variables in the target rule text are checked according to the symbol table to see if they have been declared. Perform a type consistency check on the target rule text to detect whether the expression type in the target rule text matches the type required by the operator or context. After the syntax integrity check, the variable reference validity check, and the type consistency check all pass, the target rule text is encapsulated into request parameters that conform to the application programming interface specification of the second rule engine; The application programming interface is invoked to send the request parameters to the second rule engine for storage, the save result returned by the application programming interface is received, and the storage status of the target rule text is determined based on the save result.

[0020] The advantages of adopting the above optional method are as follows: after further verifying the syntactic integrity, variable reference validity and type consistency of the target rule text, the interface is called for storage, which solves the problem of delayed exposure of runtime errors caused by missing rule structure, undeclared variables or type mismatch, and improves the reliability of rule storage and the running stability of the target engine.

[0021] Secondly, this invention provides an insurance rule migration system based on a large model and automation. The technical solution of this system is as follows: The acquisition module is used to acquire the source rule text written according to the syntax of the first rule engine; The analysis module is used to perform lexical and syntactic analysis on the source rule text through a syntax parsing framework, and generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text. The extraction module is used to traverse the abstract syntax tree and extract rule structure information, which includes conditional expressions, action statements, and variable definitions. The mapping module is used to map the rule structure information to the template engine, and the template engine generates intermediate rule text according to the preset transformation template; The correction module is used to input the intermediate rule text into the large model, and perform semantic correction on the intermediate rule text through the large model to generate target rule text that conforms to the syntax of the second rule engine. The verification module is used to perform syntax verification on the target rule text. After the verification is passed, the application programming interface of the second rule engine is called to store the target rule text in the second rule engine.

[0022] The beneficial effects of the insurance rule migration system based on a large model and automation proposed in this invention are as follows: The system of this invention performs lexical and syntactic analysis on the source rule text using a syntax parsing framework to generate an abstract syntax tree. It then traverses and extracts rule structure information and maps it to a template engine to generate intermediate rule text. A large model then performs semantic correction to generate the target rule text. Finally, after syntactic verification, the text is stored in the target rule engine. This solves the problems of time-consuming manual migration, huge manpower and time costs, heavy burden on business personnel to learn a completely new syntax system, easy logical errors due to manual conversion, lack of real-time syntax checking leading to the exposure of rule errors only at runtime, and difficulty in ensuring version consistency. It achieves automated and precise migration of insurance rules, reduces migration costs and business personnel learning costs, improves migration efficiency and rule accuracy, and ensures the technical autonomy, controllability, and stable operation of the core business system.

[0023] Thirdly, the technical solution of an electronic device according to the present invention is as follows: It includes a memory, a processor, and a program stored in the memory and running on the processor, wherein the processor executes the program to implement the steps of the insurance rule migration method based on a large model and automation as described in this invention.

[0024] Fourthly, the technical solution of a computer-readable storage medium provided by the present invention is as follows: The computer-readable storage medium stores instructions that, when read, cause the computer-readable storage medium to perform the steps of the insurance rule migration method based on large models and automation of the present invention.

[0025] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0026] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating an embodiment of an insurance rule migration method based on a large model and automation according to the present invention. Figure 2 This is a schematic diagram illustrating the overall principle of an embodiment of an insurance rule migration method based on a large model and automation according to the present invention. Figure 3 This is a schematic diagram of an embodiment of an insurance rule migration system based on a large model and automation according to the present invention. Figure 4 This is a schematic diagram of an embodiment of an electronic device according to the present invention. Detailed Implementation

[0027] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0028] Figure 1 This diagram illustrates a flowchart of an embodiment of an insurance rule migration method based on a large model and automation provided by the present invention. This method can be executed by electronic devices such as terminal devices or servers. The terminal device can be any fixed or mobile terminal, such as user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, or wearable device. The server can be a single server or a server cluster consisting of multiple servers. Any electronic device can implement the insurance rule migration method based on a large model and automation by having its processor call computer-readable instructions stored in its memory. Figure 1 As shown, it includes the following steps: S1. Obtain the source rule text written according to the syntax of the first rule engine.

[0029] The first rule engine refers to the rule engine whose syntax follows the source rule, typically a foreign commercial rule engine that needs to be replaced; for example, the IBMILOG rule engine. The original rule is written according to the IBMILOG rule engine syntax, and the rule text is "ruleR001{when insurance policy A. vehicle B. rated load capacity > 10tthen refuse insurance;}". The source rule text refers to the original rule content written according to the syntax of the first rule engine; for example, the source rule text is "ruleR001{when insurance policy A. vehicle B. rated load capacity > 10tthen refuse insurance;}".

[0030] S2. Perform lexical and syntactic analysis on the source rule text using a syntax parsing framework to generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text.

[0031] Among them, a syntax parsing framework refers to a software framework used for lexical and syntactic analysis of rule text, which can generate an abstract syntax tree based on predefined grammar rules; for example, the ANTLR4 syntax parsing framework is used to parse rule text of IBMI LOG rule engine syntax.

[0032] Lexical analysis refers to the process of breaking down the input rule text character stream into meaningful lexical units. For example, performing lexical analysis on the source rule text "Insurance Policy A. Vehicle B. Approved Load Capacity > 10t" yields the lexical unit sequence [Insurance Policy A,., Vehicle B,., Approved Load Capacity,>,10,t]. Syntax analysis refers to the process of checking whether the lexical unit sequence conforms to the grammatical structure according to grammatical rules and constructing an abstract syntax tree. For example, the parser checks whether the lexical unit sequence conforms to the grammatical rules of the IBMI LOG rule engine and generates an abstract syntax tree representing the logical structure of the rules.

[0033] Logical structure refers to the logical relationship between conditions and actions in a rule, as well as the nesting hierarchy of its components. For example, the condition and action parts in the rule "when...then..." constitute the rule's logical structure. Syntactic hierarchy refers to the hierarchical relationship between different syntactic elements in the rule text, such as nested expressions and statement blocks. For example, in the conditional expression "Insurance Policy A. Vehicle B. Rated Load Capacity > 10t", the attribute access "Insurance Policy A. Vehicle B. Rated Load Capacity" constitutes one level, while the comparison operator ">" and the numerical value "10t" constitute another level.

[0034] In this context, an abstract syntax tree (AST) refers to an intermediate representation of a rule syntax structure in a tree-like format, where each node corresponds to a syntax element. For example, the root node of an AST is a rule node, and its child nodes include condition nodes (conditional expressions) and action nodes (rejection statements).

[0035] S3. Traverse the abstract syntax tree and extract rule structure information, which includes conditional expressions, action statements, and variable definitions.

[0036] Among them, rule structure information refers to the core elements of the rule extracted from the abstract syntax tree, including conditional expressions, action statements, and variable definitions; for example, the conditional expression extracted from the abstract syntax tree is "insurance policy A. vehicle B. rated load capacity > 10t", the action statement is "reject insurance", and the variable definition is "insurance policy A".

[0037] Here, the conditional expression refers to the logical condition used in the rule to determine whether to execute an action; for example, the conditional expression "Insurance Policy A. Vehicle B. Approved Load Capacity > 10t" means that the condition is met when the approved load capacity is greater than 10 tons. The action statement refers to the operation performed when the condition in the rule is met; for example, the action statement "Reject Insurance" means refusing to insure the insurance policy. The variable definition refers to the declaration of variables used in the rule and their types; for example, the variable definition "Insurance Policy A: PolicyObject" indicates that Insurance Policy A is a business object.

[0038] S4. Map the rule structure information to the template engine, and the template engine generates intermediate rule text according to the preset conversion template.

[0039] Here, a template engine refers to a software component that dynamically fills in data to generate text based on a preset template; for example, the Velocity template engine is used to fill rule structure information into a transformation template to generate intermediate rule text. A transformation template refers to a predefined text template used to convert source rule syntax into target rule syntax; for example, a transformation template for a domestically developed rule engine might contain placeholders for "if ${condition} then ${action}". Intermediate rule text refers to rule text generated by the template engine after initial transformation but before semantic correction; for example, intermediate rule text might be "if insurance policy A. vehicle B. rated load capacity > 10t then refuse insurance".

[0040] S5. Input the intermediate rule text into the large model, and use the large model to perform semantic correction on the intermediate rule text to generate target rule text that conforms to the syntax of the second rule engine.

[0041] Semantic correction refers to using a large model to semantically understand and adjust the intermediate rule text, eliminate ambiguity, correct errors, and generate text that conforms to the grammatical habits of the target engine. For example, the E large model corrects "if insurance policy A. vehicle B. rated load capacity > 10t then reject insurance" to "if getLoadCapacity(application.vehicle) > 10 then reject".

[0042] The second rule engine refers to the target rule engine, which is usually a domestically developed rule engine to which the source rules need to be migrated. For example, the syntax of a domestically developed rule engine differs from that of the IBM ILOG rule engine. The target rule text refers to the final rule text generated after semantic correction and conforming to the syntax of the second rule engine. For example, the target rule text is "ifgetLoadCapacity(application.vehicle)>10 then reject".

[0043] S6. Perform syntax validation on the target rule text, and after the validation passes, call the application programming interface of the second rule engine to store the target rule text in the second rule engine.

[0044] Syntax validation refers to checking the syntax of the rule text to ensure it conforms to the target engine's syntax specifications; for example, it involves checking the correctness of keywords, parentheses, and statement structure. Application Programming Interface (API) refers to the programming interface provided by the target rule engine for rule storage; for example, a REST API provided by a domestically developed rule engine for uploading and persisting rules.

[0045] The technical solution of this embodiment uses a syntax parsing framework to perform lexical and syntactic analysis on the source rule text to generate an abstract syntax tree. It then traverses and extracts rule structure information and maps it to a template engine to generate intermediate rule text. A large model then performs semantic correction to generate the target rule text. Finally, after syntax verification, it is stored in the target rule engine. This solution solves the problems of time-consuming manual migration, huge manpower and time costs, heavy burden on business personnel to learn a new syntax system, easy logical errors due to manual conversion, lack of real-time syntax checking leading to the exposure of rule errors only at runtime, and difficulty in ensuring version consistency. It realizes automated and accurate migration of insurance rules, reduces migration costs and business personnel learning costs, improves migration efficiency and rule accuracy, and ensures the technical autonomy, controllability, and stable operation of the core business system.

[0046] In one alternative approach, S1 specifically includes: Raw rule data is collected from the first rule engine platform.

[0047] The first rule engine platform refers to the runtime platform or repository of the source rule engine; for example, the IBM ILOG rule engine rule management platform stores the raw rule data. Raw rule data refers to unprocessed rule information collected from the first rule engine platform, which may include rule text, metadata, etc.; for example, a rule XML file exported from the IBM ILOG rule engine platform contains the definition of rule R001.

[0048] The original rule data is parsed to generate structured rule information.

[0049] Structured rule information refers to rule information with a clear field structure obtained after parsing the original rule data; for example, the rule name R001, the condition text "insurance application A. vehicle B. rated load capacity > 10t", and the action text "reject insurance" obtained after parsing XML.

[0050] The terminology of the business objects in the structured rule information is converted according to the preset business object terminology mapping relationship.

[0051] Among them, the business object terminology mapping relationship refers to the correspondence between the differences in business object naming between the source rule engine and the target rule engine; for example, "insurance policy A" in the IBM ILOG rule engine corresponds to "application" in the domestic rule engine, "vehicle B" corresponds to "vehicle", and "approved load capacity" corresponds to "loadCapacity".

[0052] Here, "business object" refers to the data entity operated on in the rule, such as an insurance application or vehicle information; for example, the business object "insurance application A" contains vehicle B information. Terminology conversion refers to replacing the business object name in the source rule with the name in the target engine based on the business object terminology mapping relationship; for example, converting "insurance application A" to "application".

[0053] The source rule text, conforming to the syntax of the first rule engine, is constructed based on the structured rule information after terminology transformation.

[0054] Among them, the structured rule information after term conversion refers to the structured rule information after term replacement; for example, the condition in the converted structured information becomes "application.vehicle.loadCapacity>10t".

[0055] Among the above optional methods, by further collecting raw rule data from the first rule engine platform and performing parsing and terminology conversion, the problem of low quality of basic migration data caused by scattered source rule data and inconsistent business object terminology is solved, thereby improving the standardization of source rule text and the reliability of subsequent conversion.

[0056] In one alternative approach, S2 specifically includes: The built-in lexical analyzer of the syntax parsing framework is invoked to scan the source rule text and split the source rule text into a sequence of lexical units.

[0057] Here, the lexical analyzer refers to the component in the syntax parsing framework responsible for lexical analysis; for example, the lexical analyzer generated by the C framework is used to break down rule text into lexical units. The lexical unit sequence refers to the ordered list of lexical units output by the lexical analyzer; for example, the lexical unit sequence is [Insurance Policy A,., Vehicle B,., Approved Load Capacity,>,10,t,then,Rejection].

[0058] The built-in parser of the syntax parsing framework is invoked to perform grammatical structure verification on the lexical unit sequence, and the abstract syntax tree reflecting the logical nesting relationship and operator precedence of the source rule text is constructed according to the predefined syntax rules.

[0059] In this context, the parser refers to the component responsible for syntax analysis within the syntax parsing framework; for example, the parser generated by the C framework is used to check the grammatical correctness of the lexical unit sequence. Syntax structure verification refers to the process by which the parser checks whether the lexical unit sequence constitutes a valid statement according to grammatical rules; for example, verifying whether "Insurance Policy A. Vehicle B. Rated Load Capacity > 10t" conforms to the syntax of attribute access and comparison operators.

[0060] Among these, syntax rules refer to the specifications that define the legal structure of a rule-based language, usually described using forms such as Backus normal form. Logical nesting refers to the hierarchical nesting between multiple conditions or actions within a rule; for example, AND / OR logical nesting in a conditional expression, such as "condition A and (condition B or condition C)". Operator precedence refers to the order in which different operators are evaluated in an expression; for example, the comparison operator ">" has lower precedence than arithmetic operators, but this is usually explicit in simple expressions.

[0061] When the parser detects that the sequence of lexical units does not conform to the predefined grammar rules, it generates corresponding grammar error information.

[0062] Among them, syntax error information refers to the error message output by the parser when it detects that the syntax does not conform to the syntax rules; for example, if the rule text is missing a semicolon, the parser outputs the error message "missing semicolon".

[0063] In the above optional methods, the built-in lexical analyzer and parser of the syntax parsing framework are further invoked, which solves the problem of deviation in the construction of abstract syntax tree caused by the difficulty of accurately identifying lexical units and grammatical structures in manual parsing, and improves the integrity of the source rule text logical structure and grammatical hierarchy preservation.

[0064] In one alternative approach, S3 specifically includes: The nodes in the abstract syntax tree are accessed according to a preset traversal order.

[0065] The traversal order refers to the order in which nodes of the abstract syntax tree are visited, such as depth-first or breadth-first traversal. For example, when using depth-first traversal, conditional nodes are visited first, followed by child nodes.

[0066] Identify condition nodes, action nodes, and variable declaration nodes based on node type.

[0067] In this context, a condition node refers to a node in the abstract syntax tree that represents a conditional expression; for example, a node in the abstract syntax tree represents the ">" operator, with the left child node representing an attribute access and the right child node representing a constant. An action node refers to a node in the abstract syntax tree that represents an action statement; for example, a node in the abstract syntax tree represents the "reject insurance" action. A variable declaration node refers to a node in the abstract syntax tree that represents a variable definition; for example, a node in the abstract syntax tree represents the variable "insurance policy A" and its type.

[0068] Obtain the child nodes contained in the condition node and combine them into a condition expression; obtain the sequence of execution statements contained in the action node as an action statement; and obtain the variable name and variable type defined in the variable declaration node as a variable definition.

[0069] The sequence of executable statements refers to one or more executable statements contained in an action node; for example, an action node might contain two statements: "Reject Insurance" and "Log to Log". The variable name refers to the identifier in the variable declaration; for example, the variable name might be "Insurance Policy A". The variable type refers to the data type in the variable declaration; for example, the variable type might be "PolicyObject".

[0070] The conditional expression, the action statement, and the variable definition are combined into the rule structure information.

[0071] In the above optional methods, the abstract syntax tree nodes are further accessed according to the preset traversal order and the condition, action and variable declaration nodes are identified. This solves the problem of incomplete extraction of rule structure information caused by disordered node traversal and type identification errors, and improves the accuracy of extracting condition expressions, action statements and variable definitions.

[0072] In one alternative approach, S4 specifically includes: The corresponding conversion template is determined from the preset template library based on the engine type of the second rule engine.

[0073] Here, "engine type" refers to the specific model or brand of the target rule engine; for example, "domestic rule engine". "Template library" refers to a collection storing multiple transformation templates, each corresponding to a target engine; for example, the template library contains transformation templates for both the domestic rule engine and the C engine.

[0074] The conditional expression, action statement, and variable definition in the rule structure information are passed to the template engine as context variables.

[0075] Context variables refer to the data set passed to the template engine to populate the template; for example, context variables include conditional expressions such as "insurance policy A. vehicle B. rated load capacity > 10t" and action statements such as "reject insurance".

[0076] The template engine dynamically fills the context variables into the corresponding positions of the conversion template according to the template instructions defined in the conversion template, and outputs the filled conversion template as the intermediate rule text.

[0077] Template directives refer to special tags in the template engine used to control the population logic; for example, the "#if" directive in the Velocity template engine is used for conditional judgment. The populated transformed template refers to the text generated after substituting context variables into the transformed template; for example, the populated template content is "if (loadCapacity>10) reject;".

[0078] In the above optional methods, the conversion template is further determined from the template library according to the second rule engine type and the context variables are dynamically populated. This solves the problem of inconsistent intermediate rule text format caused by incorrect template selection and misaligned variable mapping, and improves the compatibility between intermediate rule text and target engine syntax.

[0079] In one alternative approach, S5 specifically includes: The intermediate rule text is input into the large model, and the large model performs rule logic decomposition on the intermediate rule text to identify the predefined part, condition part and action part.

[0080] Rule logic decomposition refers to the process of splitting rule text into predefined parts, condition parts, and action parts; for example, a rule can be split into the predefined part "rule R001", the condition part "insurance application A. vehicle B. rated load capacity > 10t", and the action part "reject insurance".

[0081] The predefined part refers to the metadata in the rule other than the conditions and actions, such as the rule name and description; for example, the predefined part is "rule R001". The condition part refers to the conditional logic used for judgment in the rule; for example, the condition part is "Insurance application A. Vehicle B. Approved load capacity > 10t". The action part refers to the operation performed when the conditions in the rule are met; for example, the action part is "Reject insurance".

[0082] Based on the preset business object terminology mapping relationship, the semantic transformation of business objects in the predefined part, the condition part and the action part is performed to eliminate the differences in business object descriptions between different rule engines.

[0083] Among them, the difference in the representation of business objects refers to the different naming or structure of the same business concept in different rule engines; for example, the IBM ILOG rule engine uses "insurance policy A", while the domestic rule engine uses "application".

[0084] According to the preset conversion logic, the semantically converted predefined part, the condition part, and the action part are mapped to grammatical elements that conform to the syntax of the second rule engine.

[0085] Transformation logic refers to the rules or strategies that map the source rule syntax to the target rule syntax; for example, transformation logic specifies that "attribute access" is converted into "getter method call". Syntax elements refer to the basic units that constitute the rule language, such as keywords, operators, and identifiers; for example, "if" and "then" in a domestically developed rule engine are syntax elements.

[0086] The mapped syntax elements are post-processed to correct abnormal statements in the text generated by the large model, and then combined to form the target rule text.

[0087] Post-processing refers to the subsequent correction of text generated by the large model, removing abnormal or non-standard content; for example, post-processing corrects extra spaces or spelling errors generated by the large model. Abnormal statements refer to text fragments generated by the large model that do not conform to grammar or semantics; for example, the large model may generate abnormal statements such as "if>then".

[0088] In the above-mentioned optional methods, the intermediate rule text is further logically split, semantically transformed, and post-processed through a large model, which solves the problem of semantic deviation of the target rule caused by differences in the expression of business objects between different engines and the residual of abnormal statements, and improves the semantic accuracy and grammatical compliance of the target rule text.

[0089] In one alternative approach, S6 specifically includes: The target rule text is subjected to grammatical integrity verification to detect whether there are any structurally missing or incomplete sentences in the target rule text.

[0090] Syntactic integrity verification refers to checking whether the rule text is structurally complete and free from missing statements or mismatched parentheses; for example, verifying whether the rule has a "then" keyword corresponding to "if".

[0091] The target rule text is subjected to variable reference validity verification, and the variables in the target rule text are checked according to the symbol table to see if they have been declared.

[0092] Among them, variable reference validity verification refers to checking whether the variables used in the rules have been declared to avoid undefined variables; for example, verifying whether “rated load capacity” is declared in the variable definition.

[0093] Perform a type consistency check on the target rule text to detect whether the expression type in the target rule text matches the type required by the operator or context.

[0094] Type consistency check refers to checking whether the types of operands in an expression match, such as strings and numbers being incomparable; for example, checking whether "rated load capacity" is a numeric type and whether it can be compared with numbers.

[0095] After the syntax integrity check, the variable reference validity check, and the type consistency check all pass, the target rule text is encapsulated into request parameters that conform to the application programming interface specification of the second rule engine.

[0096] The request parameters refer to the parameters encapsulated when calling the application programming interface, which include the target rule text; for example, the request parameters are in JSON format and include the rule name "R001" and the rule content "if getLoadCapacity(application.vehicle)>10 then reject".

[0097] The application programming interface is invoked to send the request parameters to the second rule engine for storage, the save result returned by the application programming interface is received, and the storage status of the target rule text is determined based on the save result.

[0098] The save result refers to the rule storage operation result returned by the application programming interface, such as success or failure; for example, a save result of "success" indicates that the rule has been saved. The storage status refers to the status information of the rule after it has been persisted, such as whether it has been saved or failed to save; for example, the storage status is "saved".

[0099] In the above optional methods, the target rule text is further checked for syntactic integrity, variable reference validity and type consistency before the interface is called for storage. This solves the problem of delayed exposure of runtime errors caused by missing rule structure, undeclared variables or type mismatch, and improves the reliability of rule storage and the running stability of the target engine.

[0100] In one alternative approach, it also includes: Scan the rules in the first rule engine platform at a set periodic interval to check for changes, including the addition, modification, or deletion of the rules. Collect the original rule data of the changes, and generate the corresponding target rule text based on the original rule data of the changes; store the target rule text in the second rule engine through the application programming interface, so that the rules in the second rule engine are synchronized with the rules in the first rule engine platform.

[0101] In the above-mentioned optional methods, the changes in the rules in the first rule engine platform are further scanned according to a set period, the original rule data of the changes are collected, the corresponding target rule text is generated and stored in the second rule engine, so that the rules in the second rule engine are kept synchronized with the rules in the first rule engine platform, avoiding version inconsistency problems caused by long migration cycles.

[0102] like Figure 2 As shown, in this embodiment, the source rule text is first processed for text structuring. The source rule text is written according to the syntax of a first rule engine, which can be the IBM ILOG rule engine. A syntax rule file compatible with the first rule engine, i.e., a g4 file, is written using the ANTLR4 syntax parsing framework. Based on the g4 file, ANTLR4 is used for syntax analysis, and a syntax parsing file, including a lexical analyzer and a syntax analyzer, is generated through command-line conversion. The lexical analyzer scans and splits the source rule text into a sequence of lexical units, and the syntax analyzer performs grammatical structure verification on the sequence of lexical units, constructing an abstract syntax tree that reflects the logical nesting relationship and operator precedence of the source rule text according to predefined syntax rules. The abstract syntax tree fully preserves the logical structure and grammatical hierarchy of the source rule text.

[0103] The abstract syntax tree is traversed to extract rule structure information, including conditional expressions, action statements, and variable definitions. This rule structure information is mapped to the Velocity template engine, where it is transformed into backend rule text guided by Velocity scripts, generating intermediate rule text. This intermediate rule text serves as the structured data input to the main model for execution. The main model then performs semantic corrections on the intermediate rule text to generate target rule text that conforms to the syntax of the second rule engine. The second rule engine is a domestically developed rule engine.

[0104] At the editor interaction level, the syntax parsing file generated by ANTLR4 is combined with the Antlr4-c3 library for syntax completion suggestions. Antlr4-c3 completes logical keyword text editing based on the suggested structure words, and also retrieves hierarchical structure completion items based on BOM data, i.e., business object hierarchical structure completion. Monaco Editor registers custom languages, integrates the above syntax parsing and completion functions, supports parsing interaction and suggestion interaction, and provides business users with an integrated development environment editing experience. The editor provides syntax highlighting, code folding, and formatting functions when users write rules, and performs real-time syntax checking, generating syntax error messages.

[0105] In another embodiment of the insurance rule migration method based on large models and automation of the present invention, the following steps are specifically included: S10. Collect raw rule data from the first rule engine platform, parse the raw rule data to generate structured rule information, perform terminology conversion on the business objects in the structured rule information according to the preset business object terminology mapping relationship, and construct source rule text that conforms to the syntax of the first rule engine.

[0106] S20. Perform lexical and syntactic analysis on the source rule text using a syntax parsing framework to generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text. Record the location and type of syntax errors during the syntax analysis process and generate corresponding syntax error messages.

[0107] S30. Traverse the abstract syntax tree, visit each node in depth-first order, identify condition nodes, action nodes and variable declaration nodes, extract condition expressions from condition nodes, extract action statements from action nodes, extract variable names and variable types from variable declaration nodes, and extract rule metadata at the same time, and combine them into rule structure information.

[0108] S40. Determine the corresponding transformation template from the template library according to the engine type of the second rule engine. Pass the conditional expression, action statement, variable definition and rule metadata in the rule structure information as context variables to the template engine. The template engine dynamically fills the context variables according to the template instructions of the transformation template to generate intermediate rule text. Perform a pre-validation of the syntax structure integrity of the intermediate rule text. If the pre-validation fails, adjust the transformation template parameters and regenerate.

[0109] S50. Input the intermediate rule text into the large model. The large model performs rule logic decomposition on the intermediate rule text to identify the predefined part, condition part and action part. According to the preset business object term mapping relationship, the business objects in the predefined part, condition part and action part are semantically transformed. According to the preset transformation logic, they are mapped into grammatical elements that conform to the syntax of the second rule engine. Combined with rule metadata, context-aware correction is performed. After post-processing to correct abnormal statements, they are combined to form the target rule text.

[0110] S60. Perform syntax integrity verification, variable reference validity verification, and type consistency verification on the target rule text. If the verification passes, call the application programming interface of the second rule engine to store the target rule text in the second rule engine. If the verification fails, trigger the automatic retry mechanism according to the error type, select template engine adjustment or large model secondary correction, until the number of retries reaches the preset threshold and then transfer to the manual processing queue.

[0111] S70. Scan the rule changes in the first rule engine platform according to the set cycle, collect the original rule data of new, modified or deleted rules, generate the corresponding target rule text according to the difference of change type and store it in the second rule engine, and record the version change history to keep the rules in the second rule engine synchronized with the rules in the first rule engine platform.

[0112] This embodiment collects raw rule data from a first rule engine platform, parses and transforms it to construct source rule text conforming to the syntax of the first rule engine. It then uses a syntax parsing framework to generate an abstract syntax tree and record syntax error information. The abstract syntax tree is traversed to extract rule structure information and rule metadata. Based on the type of the second rule engine, a transformation template is selected to generate intermediate rule text, which is then pre-validated. The intermediate rule text is input into a large model for rule logic decomposition, semantic transformation, context-aware correction, and post-processing to form the target rule text. The target rule text undergoes multiple validations, and an automatic retry mechanism is triggered based on the error type when validation fails. Changes to the first rule engine platform are scanned periodically, and the target rule text is generated and synchronized to the second rule engine accordingly. This solves the problems of time-consuming manual migration, huge manpower and time costs, heavy burden on business personnel learning a new syntax system, easy logical errors in manual transformation, lack of real-time syntax checking leading to runtime error exposure, and difficulty in ensuring version consistency. It achieves automated and precise migration of insurance rules, reduces migration costs and business personnel learning costs, improves migration efficiency and rule accuracy, and ensures the technical autonomy and stable operation of the core business system.

[0113] Figure 3 This diagram illustrates the structure of an embodiment of an insurance rule migration system 200 based on a large model and automation, provided by the present invention. Figure 3 As shown, the insurance rule migration system 200 based on a large model and automation includes: Module 201 is used to obtain the source rule text written according to the syntax of the first rule engine; Analysis module 202 is used to perform lexical and syntactic analysis on the source rule text through a syntax parsing framework to generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text; Extraction module 203 is used to traverse the abstract syntax tree and extract rule structure information, which includes conditional expressions, action statements and variable definitions; The mapping module 204 is used to map the rule structure information to the template engine, and the template engine generates intermediate rule text according to the preset conversion template. The correction module 205 is used to input the intermediate rule text into the large model, and perform semantic correction on the intermediate rule text through the large model to generate target rule text that conforms to the syntax of the second rule engine. The verification module 206 is used to perform syntax verification on the target rule text, and after the verification is passed, it calls the application programming interface of the second rule engine to store the target rule text in the second rule engine.

[0114] In one alternative embodiment, the acquisition module 201 is specifically used for: Raw rule data is collected from the first rule engine platform; The original rule data is parsed to generate structured rule information; The terminology of the business objects in the structured rule information is converted according to the preset business object terminology mapping relationship; The source rule text, conforming to the syntax of the first rule engine, is constructed based on the structured rule information after terminology transformation.

[0115] In an alternative embodiment, the analysis module 202 is specifically used for: The built-in lexical analyzer of the syntax parsing framework is invoked to scan the source rule text and split the source rule text into a sequence of lexical units; The built-in parser of the syntax parsing framework is invoked to perform grammatical structure verification on the lexical unit sequence, and the abstract syntax tree reflecting the logical nesting relationship and operator precedence of the source rule text is constructed according to the predefined syntax rules; When the parser detects that the sequence of lexical units does not conform to the predefined grammar rules, it generates corresponding grammar error information.

[0116] In an alternative embodiment, the extraction module 203 is specifically used for: Visit each node in the abstract syntax tree according to the preset traversal order; Identify condition nodes, action nodes, and variable declaration nodes based on node type; Obtain the child nodes contained in the condition node and combine them into a condition expression; obtain the sequence of execution statements contained in the action node as an action statement; obtain the variable name and variable type defined in the variable declaration node as a variable definition. The conditional expression, the action statement, and the variable definition are combined into the rule structure information.

[0117] In an alternative embodiment, the mapping module 204 is specifically used for: The corresponding conversion template is determined from the preset template library based on the engine type of the second rule engine; The conditional expression, action statement, and variable definition in the rule structure information are passed to the template engine as context variables. The template engine dynamically fills the context variables into the corresponding positions of the conversion template according to the template instructions defined in the conversion template, and outputs the filled conversion template as the intermediate rule text.

[0118] In an alternative embodiment, the correction module 205 is specifically used for: The intermediate rule text is input into the large model, and the large model performs rule logic decomposition on the intermediate rule text to identify the predefined part, condition part and action part; Based on the preset business object terminology mapping relationship, semantic transformation is performed on the business objects in the predefined part, the condition part and the action part to eliminate the differences in business object expression between different rule engines; According to the preset conversion logic, the semantically converted predefined part, the condition part, and the action part are mapped to syntactic elements that conform to the syntax of the second rule engine. The mapped syntax elements are post-processed to correct abnormal statements in the text generated by the large model, and then combined to form the target rule text.

[0119] In an alternative embodiment, the verification module 206 is specifically used for: Perform a syntactic integrity check on the target rule text to detect whether the target rule text contains missing or incomplete sentences. The target rule text is subjected to variable reference validity verification, and the variables in the target rule text are checked according to the symbol table to see if they have been declared. Perform a type consistency check on the target rule text to detect whether the expression type in the target rule text matches the type required by the operator or context. After the syntax integrity check, the variable reference validity check, and the type consistency check all pass, the target rule text is encapsulated into request parameters that conform to the application programming interface specification of the second rule engine; The application programming interface is invoked to send the request parameters to the second rule engine for storage, the save result returned by the application programming interface is received, and the storage status of the target rule text is determined based on the save result.

[0120] It should be noted that the beneficial effects of the insurance rule migration system 200 based on a large model and automation provided in the above embodiments are the same as those of the insurance rule migration method based on a large model and automation, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0121] The insurance rule migration system 200 based on large models and automation of the present invention can be a computer program (including program code) running on a computer device. For example, the insurance rule migration system 200 based on large models and automation of the present invention is an application software that can be used to execute the corresponding steps in the insurance rule migration method based on large models and automation of the present invention.

[0122] In some embodiments, the insurance rule migration system 200 based on large models and automation of the present invention can be implemented in a combination of hardware and software. As an example, the insurance rule migration system 200 based on large models and automation of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the insurance rule migration method based on large models and automation of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0123] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0124] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned insurance rule migration methods based on large models and automation. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the insurance rule migration method based on large models and automation shown in any embodiment of the present invention by calling the computer program.

[0125] In one alternative embodiment, an electronic device is provided, such as Figure 4 As shown, Figure 4 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0126] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0127] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0128] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0129] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0130] Among them, electronic devices can also be terminal devices. A terminal device can be any terminal device that can install applications and access web pages through applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0131] It should be noted that, Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0132] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned insurance rule migration methods based on large models and automation.

[0133] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0134] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned insurance rule migration method based on large models and automation.

[0135] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0136] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0137] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0138] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0139] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0140] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0141] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

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

Claims

1. A method for transferring insurance rules based on large models and automation, characterized in that, include: Retrieve the source rule text written according to the syntax of the first rule engine; The source rule text is subjected to lexical and syntactic analysis using a syntax parsing framework to generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text. Traverse the abstract syntax tree to extract rule structure information, which includes conditional expressions, action statements, and variable definitions. The rule structure information is mapped to the template engine, which then generates intermediate rule text based on a preset transformation template. The intermediate rule text is input into the large model, and the large model performs semantic correction on the intermediate rule text to generate target rule text that conforms to the syntax of the second rule engine. The target rule text is subjected to syntax validation. After the validation passes, the application programming interface of the second rule engine is called to store the target rule text in the second rule engine.

2. The insurance rule migration method based on large models and automation according to claim 1, characterized in that, The steps to obtain the source rule text written according to the syntax of the first rule engine include: Raw rule data is collected from the first rule engine platform; The original rule data is parsed to generate structured rule information; The terminology of the business objects in the structured rule information is converted according to the preset business object terminology mapping relationship; The source rule text, conforming to the syntax of the first rule engine, is constructed based on the structured rule information after terminology transformation.

3. The insurance rule migration method based on large models and automation according to claim 1, characterized in that, The steps of performing lexical and syntactic analysis on the source rule text using a syntax parsing framework to generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text include: The built-in lexical analyzer of the syntax parsing framework is invoked to scan the source rule text and split the source rule text into a sequence of lexical units; The built-in parser of the syntax parsing framework is invoked to perform grammatical structure verification on the lexical unit sequence, and the abstract syntax tree reflecting the logical nesting relationship and operator precedence of the source rule text is constructed according to the predefined syntax rules; When the parser detects that the sequence of lexical units does not conform to the predefined grammar rules, it generates corresponding grammar error information.

4. The insurance rule migration method based on large models and automation according to claim 3, characterized in that, The steps of traversing the abstract syntax tree and extracting rule structure information include: Visit each node in the abstract syntax tree according to the preset traversal order; Identify condition nodes, action nodes, and variable declaration nodes based on node type; Obtain the child nodes contained in the condition node and combine them into a condition expression; obtain the sequence of execution statements contained in the action node as an action statement; obtain the variable name and variable type defined in the variable declaration node as a variable definition. The conditional expression, the action statement, and the variable definition are combined into the rule structure information.

5. The insurance rule migration method based on large models and automation according to claim 4, characterized in that, The steps of mapping the rule structure information to a template engine, and having the template engine generate intermediate rule text based on a preset transformation template, include: The corresponding conversion template is determined from the preset template library based on the engine type of the second rule engine; The conditional expression, action statement, and variable definition in the rule structure information are passed to the template engine as context variables. The template engine dynamically fills the context variables into the corresponding positions of the conversion template according to the template instructions defined in the conversion template, and outputs the filled conversion template as the intermediate rule text.

6. The insurance rule migration method based on large models and automation according to claim 5, characterized in that, The steps of inputting the intermediate rule text into the large model, semantically correcting the intermediate rule text through the large model, and generating target rule text that conforms to the syntax of the second rule engine include: The intermediate rule text is input into the large model, and the large model performs rule logic decomposition on the intermediate rule text to identify the predefined part, condition part and action part; Based on the preset business object terminology mapping relationship, semantic transformation is performed on the business objects in the predefined part, the condition part and the action part to eliminate the differences in business object expression between different rule engines; According to the preset conversion logic, the semantically converted predefined part, the condition part, and the action part are mapped to syntactic elements that conform to the syntax of the second rule engine. The mapped syntax elements are post-processed to correct abnormal statements in the text generated by the large model, and then combined to form the target rule text.

7. The insurance rule migration method based on large models and automation according to claim 6, characterized in that, The steps of performing syntax validation on the target rule text, and then, after passing the validation, calling the application programming interface of the second rule engine to store the target rule text into the second rule engine, include: Perform a syntactic integrity check on the target rule text to detect whether the target rule text contains missing or incomplete sentences. The target rule text is subjected to variable reference validity verification, and the variables in the target rule text are checked according to the symbol table to see if they have been declared. Perform a type consistency check on the target rule text to detect whether the expression type in the target rule text matches the type required by the operator or context. After the syntax integrity check, the variable reference validity check, and the type consistency check all pass, the target rule text is encapsulated into request parameters that conform to the application programming interface specification of the second rule engine; The application programming interface is invoked to send the request parameters to the second rule engine for storage, the save result returned by the application programming interface is received, and the storage status of the target rule text is determined based on the save result.

8. An insurance rule migration system based on a large model and automation, characterized in that, include: The acquisition module is used to acquire the source rule text written according to the syntax of the first rule engine; The analysis module is used to perform lexical and syntactic analysis on the source rule text through a syntax parsing framework, and generate an abstract syntax tree that preserves the logical structure and syntactic hierarchy of the source rule text. The extraction module is used to traverse the abstract syntax tree and extract rule structure information, which includes conditional expressions, action statements, and variable definitions. The mapping module is used to map the rule structure information to the template engine, and the template engine generates intermediate rule text according to the preset transformation template; The correction module is used to input the intermediate rule text into the large model, and perform semantic correction on the intermediate rule text through the large model to generate target rule text that conforms to the syntax of the second rule engine. The verification module is used to perform syntax verification on the target rule text. After the verification is passed, the application programming interface of the second rule engine is called to store the target rule text in the second rule engine.

9. An electronic device, characterized in that, The electronic device includes a processor coupled to a memory storing at least one computer program, which is loaded and executed by the processor to enable the electronic device to implement the insurance rule migration method based on a large model and automation as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which, when executed by a processor, implements the insurance rule migration method based on a large model and automation as described in any one of claims 1 to 7.

Images