Method and system for generating an equity draw rate table

Abstract

The present specification provides a method and system for generating a benefit withdrawal rate table, comprising: obtaining contract analysis information corresponding to an insurance contract and a premium rate table respectively, the contract analysis information comprising information of a plurality of elements obtained by analyzing the insurance contract from the insurance benefit withdrawal dimension; based on the contract analysis information, splitting a whole generation task of generating a whole benefit withdrawal rate table corresponding to the premium rate table into a plurality of sub-tasks, wherein at least one element between any two sub-tasks is different; generating a local benefit withdrawal rate table corresponding to each sub-task; and fusing the local benefit withdrawal rate tables to obtain the whole benefit withdrawal rate table corresponding to the premium rate table. The method and system can improve the efficiency and quality of generating the benefit withdrawal rate table, and enable the system to run safely, stably and effectively, thereby improving the performance and robustness of the system.

Description

Technical Field

[0001] This specification relates to the field of artificial intelligence technology, and in particular to a method and system for generating a rights claim rate table. Background Technology

[0002] As the insurance business continues to develop, insurance companies and their authorized sales agencies need to prepare and use corresponding benefit claim rate tables in accordance with insurance terms in their daily operations. For example, the insurance product can be a life insurance product, and the benefit claim rate table can be an annuity rate table.

[0003] In related technologies, the creation and verification of benefit claim rate tables are mainly done manually. However, this method has drawbacks such as low efficiency and susceptibility to errors.

[0004] With the development of artificial intelligence technology, network models (such as Large Language Models, LLM) can also be used to generate benefit claim rate tables. However, insurance product terms often contain a large amount of irrelevant or redundant information, which can easily mislead the model, resulting in insufficient accuracy and reliability of the output benefit claim rate table. In addition, since benefit claim rate tables typically contain tens of thousands of rows of data, the processing power of large language models is insufficient to handle such a large-scale data generation task, thus making it difficult to guarantee both generation efficiency and quality.

[0005] It should be noted that the above-mentioned related technologies are only information known to the inventor personally, and do not mean that the above information had entered the public domain before the application date of this specification, nor do they mean that it can be considered prior art in this specification. Summary of the Invention

[0006] This specification provides a method and system for generating a claims payout rate table to avoid at least one of the aforementioned technical problems.

[0007] Firstly, this specification provides a method for generating a rights claim rate table, including: Obtain the contract parsing information and premium rate table corresponding to the insurance contract respectively. The contract parsing information includes information on various elements obtained from parsing the insurance contract from the perspective of insurance rights and benefits. Based on the contract parsing information, the overall task of generating the overall benefit claim rate table corresponding to the insurance premium rate table is divided into several sub-tasks, wherein at least one element differs between any two sub-tasks; and Generate the local benefit claim rate table corresponding to each subtask, and merge the local benefit claim rate tables to obtain the overall benefit claim rate table corresponding to the insurance premium rate table.

[0008] Secondly, this specification provides a system for generating a rights claim rate table, including: At least one storage medium stores at least one set of instructions for generating a claim rate table; At least one processor is communicatively connected to the at least one storage medium, wherein when the at least one processor is running, it reads the at least one instruction set and executes the method as described in the first aspect according to the instructions of the at least one instruction set.

[0009] Thirdly, this specification provides a computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, which is executed by at least one processor to implement the method as described in the first aspect.

[0010] As can be seen from the above technical solutions, the method and system for generating the claim rate table provided in this specification can improve the efficiency and quality of claim rate table generation by transforming the overall task of generating the claim rate table, especially when the overall task is large and coupled, into a series of independently processable, reusable, and optimizable subtasks. This also enables the system used to generate the claim rate table to operate safely, stably, and effectively, thereby improving the system's performance and robustness.

[0011] The methods for generating the claims payout rate table and other functions of the system provided in this specification are partially listed in the following description. The inventive aspects of the methods and systems for generating the claims payout rate table provided in this specification can be fully explained through practice or by using the methods, apparatus, and combinations described in the detailed examples below. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A schematic diagram illustrating an application scenario of the method for generating a rights claim rate table provided in the embodiments of this specification; Figure 2 A schematic diagram of the structure of the system for generating the claim fee rate table provided in the embodiments of this specification; Figure 3 A flowchart illustrating a method for generating a claims claim rate table as provided in one embodiment of this specification; Figure 4 A schematic diagram illustrating the principle of a method for generating a claims claim rate table as provided in one embodiment of this specification; Figure 5A flowchart illustrating a method for generating a claims claim rate table as provided in one embodiment of this specification; Figure 6 This is a schematic diagram illustrating the principle of a method for generating a claims claim rate table, provided as an embodiment of this specification. Detailed Implementation Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0014] It should be understood that the terms “comprising” and “having”, and any variations thereof, in the embodiments of this specification are intended to cover but not exclude inclusion. For example, a product or device that includes a series of components is not necessarily limited to those components that are explicitly listed, but may include other components that are not explicitly listed or that are inherent to such product or device.

[0015] The term "and / or" in the embodiments of this specification describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0016] In the embodiments of this specification, the term "multiple" refers to two or more, and other quantifiers are similar.

[0017] The terms “first,” “second,” “third,” etc., used in this specification are used to distinguish similar or related objects or entities and do not necessarily imply a specific order or sequence, unless otherwise indicated. It should be understood that such terms can be used interchangeably where appropriate, for example, in situations where implementation can proceed in an order other than those given in the embodiments illustrated or described in this specification.

[0018] As used in this specification, the term "unit / module" means any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code capable of performing the functions associated with that element.

[0019] To facilitate the reader's understanding of this manual, at least some of the terms used in this manual are explained below: Large language models are artificial intelligence models capable of understanding, analyzing, and generating natural language text. They possess powerful semantic understanding and knowledge reasoning capabilities, enabling them to efficiently handle complex language tasks.

[0020] In this specification, the Large Language Model (LLM) may also be referred to simply as the Large Model. A Large Language Model is a natural language processing model based on deep learning techniques, typically with billions to hundreds of billions or even more parameters, possessing powerful language understanding and generation capabilities. Large Language Models can employ the Transformer architecture or its variants (such as GPT, BERT, etc.), which utilizes an attention mechanism to globally model sequential data, efficiently handling long-distance dependencies and thus performing exceptionally well in natural language tasks. Large Language Models learn the statistical features and semantic relationships of language through pre-training on large-scale corpora, giving them outstanding generalization capabilities. The core capabilities of Large Language Models include, but are not limited to: understanding contextual semantics, generating coherent and grammatically correct text, performing logical reasoning, and handling multi-task scenarios. Its usage typically includes two modes: direct inference and fine-tuning. In direct inference mode, the user guides the Large Language Model to generate specific outputs by designing prompts. Cue words can be task descriptions or instructions in text form, used to stimulate the semantic understanding and generation capabilities of large language models. In fine-tuning mode, large language models are further trained on small-scale datasets in specific domains to optimize their performance on specific tasks. The powerful generalization ability and flexibility of large language models make them an important tool in the field of artificial intelligence, providing efficient and accurate solutions for automated text generation and understanding.

[0021] In some embodiments, large language models can also understand and generate data from other modalities (such as visual and audio data). In this case, large language models can also be called multimodal large language models (MLLMs). MLLMs provide a richer and more natural interactive experience by integrating multiple types of input and output, such as text, images, and sound. The core advantage of MLLMs lies in their ability to process and understand information from different modalities and fuse this information to complete complex tasks. For example, MLLMs can analyze an image and generate descriptive text, or generate a corresponding image based on a text description. This cross-modal understanding and generation capability makes MLLMs widely applicable across multiple fields.

[0022] It should be noted that the key technologies of large language models can be found in the detailed description in the paper "A Survey of Large Language Models" (paper number: arXiv:2303.18223v16, published on March 11, 2025, public link: https: / / doi.org / 10.48550 / arXiv.2303.18223), and will not be repeated here.

[0023] Retrieval Enhancement Generation Augmented Generation (RAG) provides large language models with information retrieved from certain data sources, serving as the basis for generating answers.

[0024] An annuity rate table is a data table used in annuity insurance products. It reflects the corresponding relationship between the annuity payout ratio or amount under different conditions (such as the insured's age, gender, payment method, coverage period, etc.) and is an important basis for illustrating the benefits of annuity insurance products and calculating premiums.

[0025] A multi-agent network refers to a distributed artificial intelligence system composed of multiple agents that cooperate and possess intelligent behaviors. These agents can divide tasks, share information, and jointly complete complex tasks, thereby improving the system's intelligence and automation level.

[0026] Prompts, or prompts, are typically used in large language models to guide user input or elicit corresponding program responses. They are applied in large language model programming and user interface design.

[0027] To avoid at least one of the technical problems mentioned in the background section, this specification proposes a technical concept developed through inventive effort: analyzing the insurance contract from the perspective of insurance benefit claim to obtain information on various elements of the insurance contract (i.e., contract analysis information of the insurance contract), and based on this contract analysis information, dividing the overall task of generating a benefit claim rate table corresponding to the insurance contract into multiple sub-tasks, and merging the partial benefit claim rate tables corresponding to each of the generated sub-tasks into a single overall benefit claim rate table corresponding to the insurance contract.

[0028] For example, after obtaining the contract parsing information, the overall generation task can be divided into n (n is an integer greater than 1) sub-tasks based on the contract parsing information. For each sub-task, a corresponding local claim rate table can be generated, thus generating n local claim rate tables. Based on this, the n local claim rate tables can be merged (e.g., concatenated) to obtain a single overall table (i.e., the overall claim rate table).

[0029] The technical solutions provided in this specification are based on the aforementioned technical concepts. As can be seen from the description of the aforementioned technical concepts, the technical solutions provided in this specification, by transforming the overall task of generating the claim rate table—especially when the overall generation task is large and coupled—into a series of independently processable, reusable, and optimizable subtasks, can improve the efficiency and quality of generating the claim rate table. Furthermore, it enables the system used to generate the claim rate table to operate securely, robustly, and effectively, thereby improving the system's performance and robustness.

[0030] To facilitate readers' understanding of this manual, the application scenarios of this manual are introduced below.

[0031] The technical solutions provided in this manual are applicable to scenarios where it is necessary to generate a table of claim rates for insurance products.

[0032] For example, the insurance product can be a life insurance product, and the benefit payment rate table can be a life annuity rate table; the insurance product can be a whole life insurance (life and death whole life insurance) product, and the benefit payment rate table can be a maturity coefficient table and a death benefit factor table corresponding to the maturity benefit; the insurance product can be a long-term care insurance product, and the benefit payment rate table can be a monthly care benefit factor table; the insurance product can be a critical illness insurance (including multiple payouts or survival benefit returns) product, and the benefit payment rate table can be a multiple payout ratio table; and so on, which will not be listed here.

[0033] It is worth noting that the above examples are merely illustrative of the application scenarios to which the technical solutions in this specification can be applied, and should not be construed as limiting the application scenarios. When examples are given later in this specification, they will primarily use life insurance products as examples, and life annuity premium rate tables as examples.

[0034] Figure 1 This diagram illustrates an application scenario of the method for generating a claims claim rate table (hereinafter referred to as the generation method) according to embodiments of this specification. The generation method of this specification can be applied to, for example... Figure 1 Scenario 100 is shown. (e.g.) Figure 1 As shown, scenario 100 may include target user 101 and a system for generating the rights and benefits claim rate table (hereinafter referred to as the generation system) 102.

[0035] Target user 101 can be the user who triggers the generation of the benefit claim rate table. For example, target user 101 can perform a target operation in generation system 102 to trigger the generation of the benefit claim rate table. In some embodiments, such as Figure 1 As shown, target user 101 can upload an insurance contract to generation system 102 to trigger the generation of the corresponding rights and benefits claim rate table.

[0036] In some embodiments, the generation system 102 can be a client, and the client can be an electronic device that provides interactive functionality to the target user 101. For example, the client can provide an interactive interface to the target user 101, where the target user 101 can perform a target operation. In some embodiments, the client executes the generation method described herein in response to detecting a target operation triggered by the target user 101. At this time, the client may store data or instructions for executing the generation method described herein, and may execute or be used to execute the data or instructions. In some embodiments, the client may include a hardware device with data information processing capabilities and the necessary programs required to drive the hardware device to execute the generation method described herein.

[0037] In some embodiments, the client may include a mobile device, tablet, laptop, built-in device in a motor vehicle, or similar content, or any combination thereof. In some embodiments, the mobile device may include a smart home device, a smart mobile device, a virtual reality device, an augmented reality device, or similar device, or any combination thereof. In some embodiments, a smart home device may include a smart TV, a desktop computer, etc., or any combination thereof. In some embodiments, a smart mobile device may include a smartphone, a personal digital assistant, a gaming device, a navigation device, etc., or any combination thereof. In some embodiments, the built-in device in a motor vehicle may include an in-vehicle computer, an in-vehicle television, etc.

[0038] In some embodiments, the client may have one or more applications (APPs) installed. An APP provides the target user 101 with the ability and interface to interact with the outside world via a network. APPs include, but are not limited to: web browser APPs, search APPs, chat APPs, shopping APPs, video APPs, financial management APPs, instant messaging tools, email clients, social media platform software, etc. In some embodiments, the target APP may be installed on the client.

[0039] In other embodiments, the generation system 102 can be a server. The server can be a server that provides various services. For example, the server can be a cloud server or a local server.

[0040] Accordingly, the generation method described in this specification can be executed on a server. In this case, the server can store data or instructions for executing the generation method described in this specification, and can execute or be used to execute the data or instructions. The service may include hardware devices with data processing capabilities and the necessary programs required to drive those hardware devices.

[0041] In some other embodiments, the generation system may include a client and a server. Accordingly, the generation methods provided in this specification may be executed partly on the client and partly on the server.

[0042] For example, the client can obtain an insurance contract uploaded by target user 101 and transmit the insurance contract to the server. The server receives the insurance contract transmitted by the client, generates a corresponding claim rate table based on the insurance contract, and transmits the claim rate table to the client. The client receives the claim rate table transmitted by the server and outputs it through its output device (such as a display interface, speaker, etc.) so that target user 101 can see it.

[0043] Figure 2 A hardware structure diagram of a generation system 200 provided according to an embodiment of this specification is shown. The generation system 200 can perform the generation methods described in this specification. The generation methods are described in other parts of this specification.

[0044] like Figure 2 As shown, the generation system 200 may include at least one storage medium 203 and at least one processor 202. In some embodiments, the generation system 200 may further include a communication port 204 and an internal communication bus 201. The generation system 200 may also include I / O components 205.

[0045] The internal communication bus 201 can connect to different system components. For example, the internal communication bus 201 can connect to storage medium 203, processor 202, communication port 204, and I / O component 205.

[0046] I / O component 205 supports input / output between system 200 and other components.

[0047] Communication port 204 is used to generate data communication between system 200 and the outside world. For example, communication port 204 can be used to generate data communication between system 200 and a network. Communication port 204 can be a wired communication port or a wireless communication port.

[0048] Storage medium 203 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 2031, a read-only storage medium (ROM) 2032, or a random access storage medium (RAM) 2033. Storage medium 203 also includes at least one instruction set stored in the data storage device. The instruction set includes computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the generation methods provided in this specification.

[0049] At least one processor 202 may be communicatively connected to at least one storage medium 203. The at least one processor 202 is used to execute the at least one instruction set described above. When the generation system 200 is running, the at least one processor 202 reads the at least one instruction set and, according to the instructions of the at least one instruction set, executes the generation method provided in this specification. The processor 202 may execute all steps included in the generation method. The processor 202 may be in the form of one or more processors. In some embodiments, the processor 202 may include one or more hardware processors, such as a microcontroller, microprocessor, reduced instruction set computer (RISC), application-specific integrated circuit (ASIC), application-specific instruction set processor (ASIP), central processing unit (CPU), graphics processing unit (GPU), physical processing unit (PPU), microcontroller unit, digital signal processor (DSP), field-programmable gate array (FPGA), advanced RISC machine (ARM), programmable logic device (PLD), any circuit or processor capable of performing one or more functions, or any combination thereof.

[0050] For illustrative purposes only, the accompanying drawings show only one processor 202 in the generation system 200. However, it should be noted that the generation system 200 may also include multiple processors. Therefore, the operations and / or method steps disclosed herein may be executed by one processor or by multiple processors in combination. For example, if the processor 202 of the generation system 200 described in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 202 (e.g., the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).

[0051] Please see Figure 3 , Figure 3 This is a flowchart illustrating a method for generating a claims claim rate table according to one embodiment of this specification. Wherein, Figure 3 The execution entity of the generation method shown can be a generation system. For a description of the generation system, please refer to the example above; it will not be repeated here.

[0052] like Figure 3 As shown, the method includes the following steps S301 to S303: S301: Obtain the contract analysis information and premium rate table corresponding to the insurance contract respectively. The contract analysis information includes information on various elements obtained from analyzing the insurance contract from the perspective of insurance rights and benefits.

[0053] An insurance contract is a legally binding insurance agreement signed between an insurance company and the policyholder. In this prospectus, an insurance contract primarily refers to one that includes clauses regarding the payment of future benefits. For example, based on the above analysis, an insurance contract can be a life insurance contract, which includes clauses regarding the payment of future annuity benefits.

[0054] An insurance premium rate table is a table that forms the basis for calculating insurance premiums for a specific insurance product. It is typically pre-set by the actuarial department and reflects the corresponding premiums under different conditions, such as the insured's age and payment period. Alternatively, an insurance premium rate table can be simply understood as a table showing how policyholders pay premiums when purchasing insurance products.

[0055] Contract parsing information refers to structured data automatically extracted from insurance contracts, focusing on the dimension of "how to claim benefits," through natural language processing or rule engines. This includes information on various elements related to "how to claim benefits," such as the insured's age range, insurance period, insurance liability, payment method, and payment period.

[0056] Based on the above examples, it can be seen that the insurance contract can be a life insurance contract. Therefore, in some embodiments, obtaining contract parsing information corresponding to the life insurance contract includes: obtaining the electronic document of the life insurance contract, parsing the electronic document, and extracting information on various elements related to annuity payments and premium rates to obtain contract parsing information. These various elements include multiple elements such as: insured gender, insured age range, insurance period, insurance liability, payment method, and payment period.

[0057] For example, the generation system can obtain a PDF of a life insurance contract, recognize the PDF to obtain the original text content in the PDF, and extract the core elements related to annuity payment and premium rates from the original text content, such as the insured's gender, insured's age range, insurance period, insurance liability, payment method, and payment period, thereby obtaining a structured document TSD including the core elements, and then obtaining the corresponding contract parsing information.

[0058] S302: Based on contract parsing information, the overall task of generating the overall benefit claim rate table corresponding to the insurance premium rate table is divided into several sub-tasks, wherein at least one element of any two sub-tasks is different.

[0059] The overall benefit payout rate table is a table that fully describes the proportion of future payable amounts for an insurance product under all applicable conditions.

[0060] Correspondingly, the task of generating the overall benefit claim rate table is called the overall generation task. For example, the overall benefit claim rate table can be an annuity claim rate table that includes all subgroups (such as different ages, genders, etc.), then the overall generation task refers to the generation task that includes all subgroups.

[0061] A subtask, as the concept corresponding to the overall task, refers to an independent computational unit obtained by breaking down the overall generation task according to the differential elements (such as age, gender, etc.) in the contract parsing information. Each subtask corresponds to the generation task of a group.

[0062] Continuing with the example of life insurance products: Assume several factors, including the insured age range, the start age for receiving benefits, the method of receiving benefits, and gender. Specifically, the insured age range is 30 to 60 years old; the start age for receiving benefits includes three options: 60, 65, and 70 years old; the method of receiving benefits is lifelong monthly payments; and the rates differ between men and women.

[0063] Therefore, "there are 3 types of starting age" and "there are 2 types of gender", which can be broken down into 6 sub-tasks as shown in Table 1.

[0064]

[0065] In other words, such as Figure 4 As shown, the overall generation task can be divided into 6 subtasks, namely Subtask 1, Subtask 2, and so on up to Subtask 6.

[0066] In some embodiments, S302 may include the following steps 11 and 12: Step 11: Based on the contract parsing information, determine several key enumeration parameters used to generate the overall rights and benefits claim rate table; the key enumeration parameters include at least one of multiple elements.

[0067] Key enumerated parameters refer to elements identified from contract parsing information that have a finite and discrete range of values ​​and have a decisive impact on the method of claiming rights. These parameters can be "exhaustively enumerated" and form the dimensional basis for task decomposition.

[0068] For example, continuing with the above example, key enumeration parameters could include: gender (male / female), starting age for receiving benefits (60 / 65 / 70 years old), and frequency of receiving benefits (monthly / annual).

[0069] In other words, an element can be understood as all structured information items related to the claim for benefits extracted from the insurance contract, including various attributes such as discrete, continuous, fixed, and conditional attributes. Key enumeration parameters can be understood as a set of finite and discrete values ​​further filtered from the contract parsing information, such as elements, used for task decomposition. That is, relatively speaking, elements are all attributes affecting the claim for benefits. Key enumeration parameters are discrete variables used for task decomposition.

[0070] For example, this step can be understood as follows: after obtaining the contract parsing information, the generation system can filter out all elements with finite discrete values ​​that affect the receipt of rights from the contract parsing information, and determine them as key enumeration parameters.

[0071] Therefore, the key enumeration parameter can be one or more of various elements. For example, continuing with the example above, elements include pickup method and gender. Then the key enumeration parameter could be pickup method and / or gender.

[0072] Step 12: Using at least one key enumeration parameter as a fixed parameter, adjust the different values ​​and / or combinations of other key enumeration parameters in sequence to break down the overall generation task into several sub-tasks.

[0073] For example, for a fixed parameter, the generation system can perform a Cartesian product expansion on other key enumerated parameters (such as all possible combinations of values). Accordingly, each combination corresponds to a subtask.

[0074] Continuing with the above example and Table 1, assuming the fixed parameter is the collection method, the generation system can combine the two key enumerated parameters, the starting age for collection (3 types) and the gender (2 types), to obtain 3×2 = 6 sub-tasks.

[0075] Based on the analysis of steps 11 and 12 above, it can be seen that in this embodiment, the generation system, by fixing one or more key enumeration parameters and adjusting the combination of other key enumeration parameters, divides the overall generation task into several sub-tasks, ensuring full coverage and no omissions in the division. This improves the comprehensiveness, accuracy, and reliability of the task division.

[0076] S303: Generate the local benefit claim rate table corresponding to each subtask, and merge the local benefit claim rate tables to obtain the overall benefit claim rate table corresponding to the insurance premium rate table.

[0077] A partial claim rate table, as opposed to the overall claim rate table, refers to the result generated by a single subtask. Multiple partial claim rate tables are combined to form the overall claim rate table.

[0078] Continuing with the examples above and Figure 4 The generation system can generate local claim rate tables corresponding to subtasks 1 through 6. For example... Figure 4As shown, the partial benefit claim rate table corresponding to subtask 1 can be abbreviated as Rate Table 1, the partial benefit claim rate table corresponding to subtask 2 can be abbreviated as Rate Table 2, the partial benefit claim rate table corresponding to subtask 3 can be abbreviated as Rate Table 3, the partial benefit claim rate table corresponding to subtask 4 can be abbreviated as Rate Table 4, the partial benefit claim rate table corresponding to subtask 5 can be abbreviated as Rate Table 5, and the partial benefit claim rate table corresponding to subtask 6 can be abbreviated as Rate Table 6.

[0079] Based on this, such as Figure 4 As shown, the generation system can combine partial benefit claim rate tables 1 to 6 to obtain the overall benefit claim rate table.

[0080] Continuing with the example above, after obtaining 6 partial benefit claim rate tables, the generation system can stitch the 6 partial benefit claim rate tables together according to the two dimensions of claiming age and gender to obtain a complete benefit claim rate table (i.e., the overall benefit claim rate table).

[0081] Furthermore, this embodiment does not limit the method for generating the partial benefit claim rate table. For example, the generation system can use a traditional actuarial engine to calculate the partial benefit claim rate table point by point using a preset formula; it can also determine the partial benefit claim rate table by using a parameterized template combined with interpolation; it can also determine the partial benefit claim rate table by using a large language model, and so on, which will not be listed here.

[0082] Based on the above analysis of S301 to S303, it can be seen that in this embodiment, the generation system improves the efficiency and quality of generating the overall claim rate table by transforming the overall generation task, especially when the overall generation task is large and coupled, into a series of independently processable, reusable, and optimizable subtasks. This also enables the generation system to operate safely, stably, and effectively, thereby improving the performance and robustness of the generation system.

[0083] Based on the above analysis, it can be seen that when generating the benefit claim rate table, the system first parses the insurance contract to obtain contract parsing information; then, based on the contract parsing information, it breaks down the task into several sub-tasks; finally, it generates the overall benefit claim rate table based on these sub-tasks (first generating partial benefit claim rate tables, then generating the overall benefit claim rate table based on the partial benefit claim rate tables). In other words, the system mainly generates the overall benefit claim rate table through three stages: parsing, task breakdown, and rate table generation.

[0084] Therefore, in some embodiments, the generation system can be a system including a multi-agent network to generate an overall claim rate table based on the multi-agent network. For example, the multi-agent network includes: a terms processing agent, a task breakdown agent, and a rate table generation agent.

[0085] Specifically, the terms processing agent is configured to obtain contract parsing information. For example, the terms processing agent can parse insurance contracts to obtain contract parsing information.

[0086] The task decomposition agent is configured to split the task into several subtasks. For example, the task decomposition agent can break down the overall generated task based on contract parsing information to obtain several subtasks.

[0087] The rate table generation agent is configured to generate the overall claim rate table. Alternatively, the rate table generation agent can generate several sub-tasks, each corresponding to a local claim rate table, and then generate the overall claim rate table based on these local claim rate tables.

[0088] Among them, the rate table generation agent can use a slow-thinking architecture network as the underlying model, so that the rate table generation agent can take into account complex instructions and a large number of details, and has excellent semantic understanding capabilities.

[0089] Compared to generating a benefit claim rate table using a single process (such as a large language model), this embodiment utilizes a multi-agent collaborative approach to generate the overall benefit claim rate table. This achieves full automation and modularity of the process, while also enabling coupled collaboration among agents, improving generation efficiency, and allowing agents to work together efficiently to complete complex overall generation tasks. In particular, it can reduce the illusion risk associated with long, complex insurance contracts, improving the accuracy and reliability of the generated overall benefit claim rate table.

[0090] To facilitate a deeper understanding of the implementation principles of the generation method in this manual, the following is combined with... Figure 5 The generation method provided in this manual will be described in more detail.

[0091] like Figure 5 As shown, the method includes: S501: Obtain the insurance contract and the corresponding premium rate table.

[0092] It is understood that, in order to avoid tedious descriptions, this embodiment will not repeat the same or similar content as the examples above.

[0093] For example, regarding the understanding of S501, please refer to the relevant description in the example S301 above, which will not be repeated here.

[0094] S502: The terms processing agent retrieves target knowledge related to the insurance contract from a pre-built insurance terminology knowledge base, and parses the insurance contract based on the target knowledge to obtain contract parsing information.

[0095] An insurance terminology knowledge base can be understood as a pre-built, structured, professional semantic resource library containing standard terms, definitions, synonyms, context rules, and related knowledge in the insurance field, as well as actuarial / business logic.

[0096] For example, based on the above analysis, it can be seen that the terms processing agent is configured to obtain contract parsing information. Therefore, in this embodiment, as... Figure 6 As shown, the clause processing agent can be specifically configured to: retrieve target knowledge related to the insurance contract from the insurance terminology knowledge base, and parse the insurance contract based on the target knowledge to obtain contract parsing information. This parsing can include analyzing the content of the clauses in the insurance contract, identifying information such as rights and obligations within the clauses, and can also include interpreting the clause content to clarify its meaning.

[0097] For example, the input for the terms processing agent can be an insurance contract (specifically, it can be a PDF, Word document, or plain text). The agent scans the insurance contract to obtain keywords such as "claim," "gender," "start date," and "age," and then queries the insurance terminology knowledge base to retrieve standard terminology entries, definition rules, and structured templates related to these keywords. The agent can then use the knowledge in the insurance terminology knowledge base, such as synonym lists, sentence templates, and constraints, to determine whether a passage truly corresponds to a specific element. For example, it can distinguish between "insured age" and "claim start age" to avoid confusion. Based on this, the agent can transform the successfully matched terms according to the element names, data types, and value ranges defined in the insurance terminology knowledge base to obtain contract parsing information.

[0098] Specifically, continuing with the above example, let's take a life insurance contract as an example again: Suppose that the life insurance contract includes the clause: "The insured may choose to receive a monthly annuity starting from the first policy anniversary after reaching the age of 60, 65, or 70, until death. Different annuity payment standards apply to men and women."

[0099] Therefore, the terms processing agent can first identify the contents of the aforementioned life insurance contract to obtain keywords such as "sixty years old", "sixty-five years old", "seventy years old", "monthly payment", "annuity", "male", and "female".

[0100] Then, the terms processing agent can search the insurance terminology knowledge base, such as by initiating a query to the insurance terminology knowledge base, to obtain results such as: Standard terminology: "starting age for receiving pension"; synonyms: {"receiving pension after reaching the age of...", "starting age for receiving pension", "age at which pension begins to be received"}; value type: set of discrete integers; valid value range: {60, 65, 70}, etc.

[0101] Finally, the terms processing agent can parse the insurance contract based on the target knowledge to obtain contract parsing information that conforms to the knowledge of the insurance field.

[0102] It is worth noting that this embodiment does not limit the method by which the terms processing agent retrieves target knowledge from the insurance terminology knowledge base. For example, the terms processing agent can use the keyword matching method shown in the example above for retrieval. Figure 6 As shown, the terms processing agent can also perform searches in the insurance terminology knowledge base by generating a RAG through enhanced retrieval. Additionally, the terms processing agent can also perform searches in the insurance terminology knowledge base through string matching.

[0103] Based on the above analysis of S502, it can be seen that in this embodiment, the clause processing agent can accurately extract elements such as the insured age, payment method, insurance liability, and annuity payment period by combining the insurance terminology knowledge base to determine the contract parsing information, thereby avoiding interference from redundant information and reducing misreading and misunderstanding of related knowledge, so as to improve the accuracy and reliability of the contract parsing information.

[0104] S503: The task decomposition agent breaks down the overall generated task into several sub-tasks based on contract parsing information.

[0105] Continuing with the examples above and Figure 6 The task decomposition agent's input includes contract parsing information and insurance premium rate tables, and its output consists of several sub-tasks, such as... Figure 6 The subtask list shown can specifically include subtask 1 through subtask 6.

[0106] For example, based on the above example, the task decomposition agent can automatically break down complex generation tasks (i.e., the overall generation task) into multiple parallel subtasks according to key enumeration parameters such as insurance liability, payment method, and annuity payment period, based on contract parsing information, in order to improve system processing efficiency.

[0107] In addition, for an understanding of the specific technical implementation of S503, please refer to the description of S302 in the above example, which will not be repeated here.

[0108] S504: Parallel call rate table generation Agent to generate local claim rate tables for each subtask in parallel, and integrate the local claim rate tables into a complete overall claim rate table.

[0109] Continuing with the examples above and Figure 6 The rate table generation agent is configured to generate the overall claim rate table. Therefore, in the case of several sub-tasks, the rate table generation agent can be specifically configured to: generate the local claim rate tables corresponding to each sub-task in parallel, and then integrate these local claim rate tables into a complete overall claim rate table.

[0110] For example, continuing to combine the above examples and Figure 4 With a total of 6 subtasks, the rate table generation agent can be called 6 times concurrently. Each rate table generation agent processes one subtask, thus generating 6 local claim rate tables in parallel through these 6 parallel calls. Based on this, the rate table generation agent can be called again to combine the 6 local claim rate tables into a complete overall claim rate table.

[0111] In some embodiments, such as Figure 6 As shown, the rate table generation agent is configured to generate a complete claim rate table in JSON format.

[0112] Accordingly, the generation system may also include a parser configured to parse the overall claim rate table in JSON format to obtain and output the overall claim rate table in Excel format.

[0113] Therefore, continuing to combine the above examples and Figure 6 The parser takes a JSON-formatted table of overall benefit claim rates as input and outputs an Excel-formatted table of overall benefit claim rates.

[0114] Based on the above analysis of S504, it can be seen that in this embodiment, the rate table is generated by concurrently calling the rate table to generate the Agent, and the corresponding local benefit claim rate table is generated by the concurrently called rate table to generate the Agent, thereby improving the efficiency and accuracy of generating the local benefit claim rate table, and thus improving the efficiency and accuracy of generating the overall benefit claim rate table.

[0115] In some embodiments, the performance of the rate table generation agent can be improved by combining it with a Prompt. For example, taking life insurance products as an example, the Prompt can define and standardize the annuity payout age range, the calculation method of the payout ratio, the JSON output format, example references, insurance liability limitations, and interpretation of key enumeration parameters, so as to make the overall benefit payout rate table output by the rate table generation agent more accurate and reliable.

[0116] In some embodiments, the rate table generation agent is configured to: perform a similarity search in a pre-built experience base for a target subtask among several subtasks, obtain the target historical rights claim knowledge corresponding to the target subtask, and generate a local rights claim rate table corresponding to the target subtask based on the target historical rights claim knowledge.

[0117] An experience base can be understood as a structured knowledge storage system that records historically generated partial benefit claim rate tables and their corresponding contextual information (such as product type, key enumeration parameter combinations, actuarial assumptions used, and audit results). Essentially, an experience base can be understood as a reusable actuarial case library.

[0118] Target historical claim knowledge refers to historical records retrieved from the experience base that are highly similar to or completely matched with the target subtask in terms of key enumeration parameters. It includes the actuarial assumptions, calculation strategies, or directly available rate factors used in the record, and is used to guide or accelerate the generation of the local claim rate table corresponding to the target subtask.

[0119] For example, continuing to combine the above examples and Figure 6 The target subtask can be any one of subtasks 1 through 6. If the target subtask is subtask 1, the rate table generation agent corresponding to subtask 1, which is called in parallel, performs a semantic similarity search from the experience base to obtain historical rights claim knowledge that is semantically corresponding to the target subtask 1, and generates a local rights claim rate table corresponding to subtask 1 based on this historical rights claim knowledge. Similarly, if the target subtask is subtask 2, the rate table generation agent corresponding to subtask 2, which is called in parallel, performs a semantic similarity search from the experience base to obtain historical rights claim knowledge that is semantically corresponding to the target subtask 2, and generates a local rights claim rate table corresponding to subtask 2 based on this historical rights claim knowledge. And so on, without further listing here.

[0120] Continuing with the example above and Table 1, assuming the target subtask is Subtask 1, i.e., the target subtask is: starting age for claiming benefits = 65 years old, gender = male, the rate table generation agent can initiate a query to the experience base. For example, the rate table generation agent can query the experience base using {insurance product type: life insurance product, claiming age: 65, gender: male} as the query criteria.

[0121] Upon inquiry, it was found that the rate table generating agent can obtain historical records (i.e., historical rights claim knowledge) that have a high semantic matching degree with the query conditions, such as interest rates and rate factors.

[0122] Correspondingly, the rate table generation agent can reuse this historical benefit claim knowledge to quickly generate a local annuity rate table corresponding to subtask 1 based on this historical benefit claim knowledge.

[0123] Based on the above analysis, it can be seen that in this embodiment, by combining the experience base to perform a search similar to the target sub-task, and generating a local rights claim rate table based on the retrieved historical rights claim knowledge, the efficiency of generating the local rights claim rate table can be improved.

[0124] Based on the above analysis, it can be seen that a multi-agent network includes a variety of different agents to generate the overall claim rate table.

[0125] In some embodiments, such as Figure 6 As shown, a multi-agent network can also include an inspection agent to audit and evaluate the quality of the generated overall claim rate table.

[0126] In other words, the detection agent can be understood as an automated review expert that replaces or assists manual review. It is an intelligent agent responsible for quality review and compliance verification of the overall benefit claim rate table. The detection agent can conduct a systematic check on the overall benefit claim rate table based on actuarial rules, product logic, and relevant requirements.

[0127] For example, the detection agent is configured to: detect the overall claim rate table, and if the detection result indicates that the overall claim rate table does not meet the preset quality requirements, generate modification suggestions corresponding to the overall claim rate table. The rate table generation agent is further configured to: regenerate the overall claim rate table based on the modification suggestions, so that the regenerated overall claim rate table meets the preset quality requirements.

[0128] Predefined quality requirements can be understood as a set of predefined, structured validation rules used to assess whether the overall benefit payout rate table is qualified. These structured validation rules may include: basic actuarial principles (such as time value of money and monotonicity of survival probability), insurance product design logic (such as insurance liability and payout logic), and relevant regulations (such as interest rate caps and reserve adequacy).

[0129] For example, taking insurance liability in the design logic of insurance products as an example, the preset quality requirements can be constraints on the rationality, consistency, and compliance of insurance liability. Specifically, if the insurance liability is "lifetime monthly annuity," then the detection agent is configured to: check whether the overall benefit payout rate table meets the liability matching requirements such as "factors increase with payout age," "gender differences," and "no negative values"; if so, the detection result indicates that the overall benefit payout rate table meets the preset quality requirements; otherwise, the detection result indicates that the overall benefit payout rate table does not meet the preset quality requirements.

[0130] In some embodiments, if the detection results indicate that the overall rights claim rate table does not meet the preset quality requirements, the detection Agent can also generate modification suggestions corresponding to the overall rights claim rate table.

[0131] For example, the detection agent can generate targeted modification suggestions based on the specific circumstances under which the overall benefit claim rate table does not meet the preset quality requirements, such as which specific requirements the overall benefit claim rate table does not meet.

[0132] In some embodiments, the detection agent can send modification suggestions to the rate table generation agent, so that the rate table generation agent can regenerate the overall benefit claim rate table according to the modification suggestions, so that the regenerated overall benefit claim rate table meets the preset quality requirements.

[0133] Based on the above analysis, it can be seen that in this embodiment, by utilizing a detection agent to perform quality audits on the generated overall rights claim rate table, fully automated quality control can be achieved. Furthermore, by modifying the suggested changes and regenerating the overall rights claim rate table to meet preset quality requirements, the final generated overall rights claim rate table can be of higher quality, thereby improving its effectiveness and reliability.

[0134] In some embodiments, the detection agent is further configured to: generate corresponding error case records and store the error case records in an experience base when the detection result indicates that the overall benefit claim rate table does not meet the preset quality requirements.

[0135] Error case logs can be understood as records created when the detection agent detects quality issues in the overall benefit claim rate table. These records encapsulate information such as the error phenomenon, context parameters, rule violations, root causes (if inferable), and corrective results. In the subsequent generation of the corresponding benefit claim rate table, error case logs serve as valuable knowledge about benefit claiming in the experience base.

[0136] For example, error case records can essentially be understood as searchable and reusable units of failure knowledge. For instance, storing error case records in an experience base allows them to serve as historical rights claim knowledge in the experience base during the later generation of the overall rights claim rate table. Moreover, this knowledge is negative, effectively reducing the likelihood of repeating the same errors.

[0137] For example, firstly, the detection agent can automatically obtain multi-dimensional information related to the error, such as the error location (which specific parameter combination is incorrect), the error behavior (such as actual value vs. expected behavior), and the context (such as the type of insurance product and the actuarial assumptions used). Then, the detection agent can assemble the above information into a structured record according to a unified format specification (schema) to obtain the corresponding error case record.

[0138] Based on the above analysis, it can be seen that in this embodiment, by generating and storing error case records, it is possible to avoid known pitfalls in advance when similar generation tasks occur in the future. This allows subsequent tasks to avoid similar errors when generating the rights and benefits claim rate table. In other words, it can improve the accuracy and reliability of generating the corresponding overall rights and benefits claim rate table.

[0139] Correspondingly, the detection agent can also be configured to generate corresponding correct case records and store them in the experience base when the detection result shows that the overall rights and benefits claim rate table meets the preset quality requirements.

[0140] In contrast to error case records, correct case records represent positive knowledge, guiding the accurate generation of the overall rights and benefits claim rate table. Similarly, the implementation principle can be found in the description of error case records in the example above, and will not be repeated here.

[0141] In other words, the experience base includes historical rights claim knowledge, which includes both positive knowledge (such as records of correct cases) and negative knowledge (such as records of incorrect cases) to guide the accurate generation of the overall rights claim rate table.

[0142] In some embodiments, to avoid the experience base from expanding with the accumulation of knowledge, leading to decreased retrieval efficiency and excessive storage space, this embodiment introduces a knowledge elimination mechanism.

[0143] For example, the historical rights and interests knowledge in the experience base is clustered to obtain several clusters. For each cluster, the usage frequency of each historical rights and interests knowledge is obtained. The usage frequency of a historical rights and interests knowledge represents the number of times that historical rights and interests knowledge is used to generate a local rights and interests fee rate table that meets the preset quality requirements. The historical rights and interests knowledge with the highest usage frequency in each cluster is retained, and other historical rights and interests knowledge in that cluster is removed from the experience base.

[0144] Clustering refers to the process of automatically grouping historical rights claim knowledge in an experience base into several clusters based on the similarity of their key enumeration parameter combinations, product characteristics, or actuarial assumptions through algorithms.

[0145] Correspondingly, a cluster is a grouping of similar knowledge formed after clustering. Relatively speaking, the knowledge within each cluster is highly similar to each other, while the differences between clusters are significant.

[0146] For example, for each historical right claim knowledge in the experience base, the generation system can vectorize the knowledge and use semantic similarity to cluster the vectorized knowledge to obtain several clusters.

[0147] For example, the generation system extracts the feature vector of each historical claim knowledge (such as claiming age, gender, product type, whether it includes a guarantee period, life table used, etc.), and uses clustering algorithms (such as K-Means, hierarchical clustering, etc.) to divide it into several clusters.

[0148] For each piece of knowledge within each cluster, the generation system can query the number of times it has been successfully reused and ultimately passed the quality check (this data is recorded each time it is successfully generated) to obtain the statistical usage count of that knowledge.

[0149] Based on this, within each cluster, only the most frequently used historical knowledge can be retained. For the remaining knowledge (even if the content is similar but used less frequently), the generation system can remove it from the experience base.

[0150] Thus, the experience base can be transformed from "massive raw records" into "a refined and representative set of knowledge", so that each cluster retains the most reliable and frequently used knowledge.

[0151] Based on the above analysis, it can be seen that in this embodiment, clustering is used to retain the most frequently used knowledge in each cluster while removing other knowledge from that cluster. This reduces redundant knowledge and avoids returning multiple similar but inconsistent knowledge sets. Furthermore, it allows for the filtering of knowledge that has been repeatedly validated in practice, while eliminating low-frequency or outdated knowledge. In addition, the significant compression of the experience base saves storage costs and makes retrieval operations within it faster and more efficient.

[0152] It is worth noting that this manual does not specify how each agent in a multi-agent network is obtained.

[0153] Taking the clause processing agent as an example: Based on the above analysis, the clause processing agent is mainly used to extract structured contract parsing information from insurance contract texts. Therefore, a large language model can be used as the base model, and this model can be trained using sample data to obtain the clause processing agent. The sample data consists of insurance contract samples and corresponding contract parsing information labels. By adjusting the parameters of the base model with the difference between the minimum contract parsing information labels and the predicted contract parsing information corresponding to the insurance contract samples predicted by the base model as the objective, the clause processing agent can be obtained.

[0154] For information on how to obtain other agents, please refer to the above examples regarding the training of agents for processing terms; they will not be listed here again.

[0155] It is worth noting that the above examples are merely illustrative of possible implementations of the generation method of this specification, and should not be construed as limiting the implementation of the generation method of this specification. For example, based on the above technical concept, some of the technical features described above can be combined to obtain new embodiments; new technical features can be added to the above examples to obtain new embodiments; some technical features can be removed from the above examples to obtain new embodiments; some technical features in the above examples can be replaced with other technical features; some technical features and their order in the above examples can be adjusted to obtain new embodiments, and so on, which will not be listed here.

[0156] Based on the above-described technical concept, this specification also provides a computer-readable non-transitory storage medium storing at least one instruction set, which, when executed by a processor, performs the steps of the generation method described in this specification.

[0157] In some possible implementations, various aspects of this specification can also be implemented as a program product comprising program code. When the program product is run on the generation system 200, the program code causes the generation system 200 to perform the steps of the generation method described in this specification. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on the generation system 200. However, the program product of this specification is not limited thereto. In this specification, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, 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 devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on build system 200, partially on build system 200, as a standalone software package, partially on build system 200 and partially on a remote build system, or entirely on remote build system 200.

[0158] It should be noted that the collection, storage, use, processing, transmission, provision, and disclosure of user-related information (such as user information in insurance contracts) involved in the technical solutions of this specification all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0159] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0160] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure is presented by way of example only and is not restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0161] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0162] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and to aid in understanding a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art, upon reading this specification, may readily identify some of the devices as separate embodiments. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. And the content of each secondary embodiment is valid even if it contains fewer than all the features of a single foregoing disclosed embodiment.

[0163] Every patent, patent application, publication of a patent application, and other material cited herein, such as articles, books, specifications, publications, documents, and literature (excluding any related historical examination documents), is referenced for all purposes relevant to this document, including in the specification and claims herein. However, in the event of any inconsistency or conflict between the descriptions, definitions, and / or terms used in the foregoing and those used herein, the descriptions, definitions, and / or terms used herein shall prevail.

[0164] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. A method for generating a rights claim rate table, comprising: Obtain the contract parsing information and premium rate table corresponding to the insurance contract respectively. The contract parsing information includes information on various elements obtained from parsing the insurance contract from the perspective of insurance rights and benefits. Based on the contract parsing information, the overall task of generating the overall benefit claim rate table corresponding to the insurance premium rate table is divided into several sub-tasks, wherein at least one element differs between any two sub-tasks; and Generate the local benefit claim rate table corresponding to each subtask, and merge the local benefit claim rate tables to obtain the overall benefit claim rate table corresponding to the insurance premium rate table.

2. The method according to claim 1, wherein, Based on the contract parsing information, the overall task of generating the benefit claim rate table corresponding to the insurance premium rate table is broken down into several sub-tasks, including: Based on the contract parsing information, several key enumeration parameters are determined for generating the overall benefit claim rate table; the key enumeration parameters include at least one of the multiple elements; and By using at least one key enumeration parameter as a fixed parameter, and sequentially adjusting different values ​​and / or combinations of other key enumeration parameters, the overall generation task can be divided into several sub-tasks.

3. The method according to claim 1, wherein, The method is applied to a system for generating a claim rate table, the system comprising a multi-agent network, which includes: a clause processing agent, a task decomposition agent, and a rate table generation agent; The terms processing agent is configured to obtain the contract parsing information; the task decomposition agent is configured to decompose the task into several sub-tasks; and the rate table generation agent is configured to generate the overall rights claim rate table.

4. The method according to claim 3, wherein, The terms processing agent is configured to obtain the contract parsing information, including: The terms processing agent is configured to retrieve target knowledge related to the insurance contract from a pre-built insurance terminology knowledge base, and parse the insurance contract based on the target knowledge to obtain the contract parsing information.

5. The method according to claim 4, wherein, The rate table generation agent is configured to generate the overall benefit claim rate table, including: The rate table generation agent is configured to generate local benefit claim rate tables for each subtask in parallel, and integrate the local benefit claim rate tables into a complete overall benefit claim rate table.

6. The method according to claim 5, wherein, The rate table generation agent is configured to generate the overall benefit claim rate table, including: The rate table generation agent is configured to: perform a similarity search in a pre-built experience base for the target subtask among the several subtasks, obtain the target historical rights claim knowledge corresponding to the target subtask, and generate a local rights claim rate table corresponding to the target subtask based on the target historical rights claim knowledge.

7. The method according to claim 3, wherein, The multi-agent network also includes a detection agent, which is configured to: detect the overall rights and benefits claim rate table, and generate modification suggestions corresponding to the overall rights and benefits claim rate table if the detection result shows that the overall rights and benefits claim rate table does not meet the preset quality requirements; The rate table generation agent is further configured to regenerate the overall benefit claim rate table according to the modification suggestions, so that the regenerated overall benefit claim rate table meets the preset quality requirements.

8. The method according to claim 7, wherein, The detection agent is also configured to generate a corresponding error case record and store the error case record in the experience base if the detection result indicates that the overall rights and benefits claim rate table does not meet the preset quality requirements.

9. The method according to claim 8, wherein, The method further includes: Clustering is performed on the historical rights and interests claim knowledge in the experience base to obtain several clusters; For each cluster, the usage count of each historical claim knowledge is obtained, where the usage count of a historical claim knowledge represents the number of times that historical claim knowledge has been used to generate a local claim fee rate table that meets the preset quality requirements; and The most frequently used historical claim knowledge in each cluster is retained, and other historical claim knowledge in that cluster is removed from the experience base.

10. The method according to claim 1, wherein, The insurance contract is a life insurance contract; the overall benefit payout rate table is an overall annuity rate table.

11. The method according to claim 10, wherein, Obtain the contract parsing information corresponding to the insurance contract, including: Obtain the electronic document of the life insurance contract; and The electronic document is parsed to extract information on various elements related to annuity payments and rates, in order to obtain the contract parsing information. These various elements include multiple elements such as insured gender, insured age range, insurance period, insurance liability, payment method, and payment period.

12. A system for generating a claims claim rate table, comprising: At least one storage medium stores at least one set of instructions for generating a claim rate table; At least one processor is communicatively connected to the at least one storage medium, wherein when the at least one processor is running, it reads the at least one instruction set and executes the method as described in any one of claims 1 to 11 according to the instructions of the at least one instruction set.

Images