A method, device, medium, and product for multi-source insurance retrieval and consistency verification.

Abstract

This application provides a method, device, medium, and product for multi-source retrieval and consistency verification in the insurance field. The method includes the following steps: acquiring heterogeneous document data in the insurance field and performing semantic parsing to construct an insurance knowledge graph containing business concepts and logical relationships; receiving user business query requests, retrieving data from the knowledge graph and sorting it by relevance to obtain a candidate evidence set; logically comparing candidate evidence fragments to identify and construct a set of business logic conflicts; calculating evidence reliability scores based on the source type and publication time of the evidence fragments, and resolving conflicts accordingly, selecting target evidence fragments from the candidate evidence set to form a consistent evidence chain; inputting the business query request and the consistent evidence chain into a generation model to generate query results and source explanation information. Implementing the technical solution provided in this application can achieve more accurate, consistent, and efficient business decision support in complex multi-source information.

Description

Technical Field

[0001] This application relates to the field of natural language processing technology, and in particular to a method, device, medium and product for insurance multi-source retrieval and consistency verification. Background Technology

[0002] With the rapid development of the insurance industry and the increasing sophistication of the financial regulatory system, the complexity of insurance product types and business rules continues to rise, leading to an explosive growth in massive amounts of heterogeneous data involving product terms, underwriting manuals, historical cases, and regulatory policies. How to efficiently retrieve, integrate, analyze, and verify the consistency of key business knowledge scattered across multiple sources has become a core requirement for ensuring insurance compliance and improving underwriting and claims efficiency.

[0003] In existing technologies, knowledge acquisition and decision support in insurance operations are typically achieved through manual review or document retrieval systems based on keyword matching. For example, after business personnel input specific keywords, the system traverses a single knowledge base and returns document fragments containing those keywords, which are then manually filtered and compared. However, in practical applications, existing shallow keyword-based retrieval methods lack deep semantic understanding and reasoning capabilities for complex logic across documents and multiple sources. They struggle to automatically detect potential conflicts between different versions of documents or rules at different levels (such as regulatory documents and internal manuals), leading to inefficient decision-making processes and a high likelihood of consistency bias. Summary of the Invention

[0004] In view of this, this application provides a method, device, medium, and product for multi-source insurance retrieval and consistency verification to solve the above problems.

[0005] Firstly, a method for multi-source insurance retrieval and consistency verification is provided, the method comprising:

[0006] Acquire heterogeneous document data in the insurance field, perform semantic parsing on the heterogeneous document data, and construct an insurance knowledge graph that includes business concepts and logical relationships between concepts;

[0007] Receive business query requests input by users, perform searches in the insurance knowledge graph based on the business query requests, sort the search results by relevance, and determine the candidate evidence set;

[0008] Logically compare each piece of evidence in the candidate evidence set to identify the business logic conflict relationship between any two pieces of evidence in the candidate evidence set, and construct an evidence conflict set based on the business logic conflict relationship.

[0009] Obtain metadata information for each evidence fragment in the candidate evidence set, determine the source type and release time of each evidence fragment based on the metadata information, and calculate the evidence reliability score corresponding to each evidence fragment based on the source type and release time.

[0010] Based on the reliability scores of each piece of evidence, the set of conflicting evidence is resolved. Based on the resolution results, the target evidence fragment is selected from the candidate evidence set to form a consistent chain of evidence.

[0011] Input the business query request and the consistent evidence chain into the generation model to generate the answer text and traceability explanation information for the business query request.

[0012] The above technical solutions, by semantically parsing heterogeneous documents in the insurance field and constructing a knowledge graph containing business concepts and logical relationships, enable business information from different sources and in different formats to be organized and retrieved within a unified semantic space. Knowledge graph-based retrieval and relevance ranking make query results more consistent with business semantic relationships, rather than relying solely on keyword matching. Through logical comparison of candidate evidence fragments and calculation of source credibility, the system automatically identifies and resolves conflicting information between different documents, generating logically consistent evidence chains. Finally, it outputs answer text with traceable evidence, enabling the system to provide more accurate, consistent, and efficient business decision support amidst complex multi-source information.

[0013] Optionally, heterogeneous document data in the insurance field is acquired, and semantic parsing is performed on the heterogeneous document data to construct an insurance knowledge graph containing business concepts and logical relationships between concepts, specifically including:

[0014] Based on a pre-defined insurance domain ontology library, the document types of heterogeneous document data are identified, and a pre-defined entity extraction template is matched according to the document type.

[0015] Using a semantic extraction model, structured extraction is performed on heterogeneous document data based on an entity extraction template to obtain insurance business entities. The entity extraction template defines target extraction fields corresponding to document types. Insurance business entities represent one or more of the following: product rights definition, underwriting risk control rules, industry compliance constraints, or historical business experience.

[0016] Identify the business relationships between various insurance business entities, store each insurance business entity as a node in a graph database, and map the business relationships as logical relationship edges connecting each node to form an insurance knowledge graph.

[0017] The above technical solution identifies document types based on an insurance domain ontology and matches entity extraction templates to achieve structured extraction of documents of different formats (such as terms, rules, cases, etc.), transforming scattered text content into unified insurance business entities. Furthermore, by mapping entity relationships to logical edges in a graph database, a knowledge graph that can be used for knowledge reasoning is formed, thereby achieving unified semantic representation and efficient knowledge retrieval of heterogeneous insurance documents.

[0018] Optionally, based on the business query request, a search is performed in the insurance knowledge graph, and the search results are ranked by relevance to determine the candidate evidence set, specifically including:

[0019] The semantic vector model is used to calculate the vector similarity between the business query request and the text information corresponding to each node in the insurance knowledge graph. The first stage of coarse ranking is performed, and relevant nodes are selected based on the similarity ranking results. The initial set of document fragments corresponding to the relevant nodes is determined.

[0020] The key business elements in the business query request are analyzed, and the initial document fragment set is filtered and retrieved in the second stage based on the preset business rule base, retaining the first document fragment containing the key business elements.

[0021] A subgraph structure is constructed with the first document fragment and business query request as nodes and the semantic association between nodes as edges. The graph neural network model is used to perform edge weight inference on the subgraph structure, and a third-stage re-ranking is performed. The second document fragment with a ranking score higher than a preset threshold is selected as the candidate evidence set.

[0022] The above technical solution calculates the similarity between the query and knowledge nodes using a semantic vector model to achieve efficient first-stage coarse-sorting retrieval; then it combines this with a business rule base for filtering to ensure that the retained document fragments are directly related to the query business elements; finally, it uses a graph neural network to reorder the subgraphs and select evidence fragments with high semantic relevance, which significantly improves the relevance and business matching degree of the candidate evidence set and improves retrieval accuracy.

[0023] Optionally, a logical comparison is performed on each evidence fragment in the candidate evidence set to identify the business logic conflict relationship between any two evidence fragments in the candidate evidence set, and an evidence conflict set is constructed based on the business logic conflict relationship, specifically including:

[0024] Call the preset business rule reasoning engine to detect whether any two pieces of evidence in the candidate evidence set are logically mutually exclusive in terms of underwriting conclusion or compensation liability. If they are logically mutually exclusive, generate a first type of conflict relationship.

[0025] The historical case reasoning engine is invoked to compare any two evidence fragments in the candidate evidence set with similar situations based on the pre-stored historical underwriting case library. If there are differences in business practices, a second type of conflict relationship is generated.

[0026] Based on the first type of conflict relationship and the second type of conflict relationship, an evidence conflict set is constructed with evidence fragments as nodes and conflict relationships as edges.

[0027] The above technical solution uses a business rule reasoning engine to detect logical mutual exclusion of evidence fragments in underwriting conclusions or compensation responsibilities, and can automatically identify business logic contradictions between texts; then, it uses a historical case reasoning engine to compare actual business differences and discover potential empirical conflicts; combining the two types of conflict relationships to form an evidence conflict set, the system can comprehensively identify and structurally store the conflict relationships between evidence, providing a clear basis for subsequent credible resolution.

[0028] Optionally, the source type and publication time of each evidence fragment are determined based on metadata information, and the evidence reliability score corresponding to each evidence fragment is calculated based on the source type and publication time, specifically including:

[0029] Identify the source type corresponding to each piece of evidence. If the source type is a regulatory document, set the first authority level weight; if the source type is a product terms, set the second authority level weight; if the source type is an underwriting manual, set the third authority level weight; if the source type is a historical case, set the fourth authority level weight. The first authority level weight value is greater than the second authority level weight value, the second authority level weight value is greater than the third authority level weight value, and the third authority level weight value is greater than the fourth authority level weight value.

[0030] Calculate the number of days between the release time of each piece of evidence and the current date, and use the exponential decay function to calculate the timeliness correction coefficient corresponding to each piece of evidence based on the number of days between the release time and the current date.

[0031] By using the timeliness correction coefficients, the authority level weights corresponding to the evidence fragments are weighted and corrected to obtain the evidence reliability score corresponding to each evidence fragment.

[0032] The above technical solution can quantify the reliability of documents from different sources by identifying the types of evidence sources and setting different authority levels and weights; it can also calculate the timeliness correction coefficient by combining the publication time to reflect the newness of the evidence content; and then obtain the evidence reliability score through weighted correction, so that the system can objectively evaluate the credibility of each evidence fragment and provide a quantifiable decision-making basis for subsequent conflict resolution.

[0033] Optionally, the evidence conflict set is resolved based on the reliability scores of each piece of evidence. Based on the resolution results, target evidence fragments are selected from the candidate evidence set to form a consistent evidence chain, specifically including:

[0034] Locate the first and second pieces of evidence that have a conflicting business logic relationship within the set of conflicting evidence;

[0035] Compare the reliability score of the first piece of evidence with the reliability score of the second piece of evidence;

[0036] If the reliability score of the first piece of evidence is greater than that of the second piece of evidence, then the first piece of evidence is marked as retained in the evidence conflict set, and the second piece of evidence is marked as removed.

[0037] After traversing the set of conflicting evidence, all evidence fragments not marked as to be removed are extracted as target evidence fragments and spliced ​​together according to the business logic hierarchy to form a consistent evidence chain.

[0038] The above technical solution can automatically determine which evidence content to retain or remove by comparing the evidence reliability scores of conflicting evidence fragments in the conflict set, thus avoiding the subjectivity of manual judgment. By traversing the conflict set and splicing the retained fragments, a logically consistent chain of evidence can be generated, thereby realizing the automatic resolution of multi-source information conflicts and ensuring the consistency and logical coherence of the final output content.

[0039] Optionally, the business query request and the consistent evidence chain are input into the generation model to generate the answer text and source explanation information for the business query request, specifically including:

[0040] Construct a prompt word template, and divide the prompt word template into a character command area, a task description area, and a context reference area;

[0041] Fill the task description area with the business query request and fill the context reference area with the consistent evidence chain to construct the input prompt information;

[0042] Input the input prompt information into the large language model, and use the attention mechanism of the large language model to capture the semantic features of each target evidence fragment in the consistent evidence chain to generate the answer text;

[0043] Extract key information fragments referenced in the answer text, reverse-match the original source of the key information fragments in the consistent evidence chain, and generate source explanation information including document name and clause location.

[0044] The above technical solution integrates business queries and consistent evidence chains into a large language model by constructing prompt word templates that include role instructions, task descriptions, and contextual references. This allows the generated answer text to fully utilize semantic information of the evidence. At the same time, it generates source explanation information through reverse matching, ensuring that the system's output answers have clear document sources and basis, thus achieving interpretability and verifiability of insurance business Q&A.

[0045] In a second aspect, an electronic device is provided, including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the above.

[0046] Thirdly, a computer-readable storage medium is provided that stores instructions which, when executed, perform the method as described in any of the preceding descriptions.

[0047] Fourthly, a computer program product containing instructions is provided, which, when run on a server, causes the server to perform the method described in the first aspect and any possible implementation thereof.

[0048] Understandably, the electronic device provided in the second aspect, the computer-readable storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the method provided in this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0049] In summary, implementing one or more technical solutions provided in this application has at least the following technical effects or advantages:

[0050] By introducing multi-layered mechanisms such as semantic parsing, knowledge graph construction, logical conflict detection, and evidence confidence assessment, this solution achieves semantic unification and structured management of multi-source heterogeneous knowledge in the insurance field. It can quickly locate and integrate key information from different sources in complex business scenarios. This solution can automatically identify logical contradictions and inconsistencies between insurance rules and clauses across documents and levels, thereby completing conflict screening and resolution at the decision-making front end and avoiding omissions and subjective biases caused by manual comparison. Simultaneously, by generating a consistent evidence chain and combining the output results of the generation model with its source explanation, the solution achieves verifiability and traceability of the insurance business question-and-answer process, improving the transparency and credibility of the system's decisions in application scenarios such as intelligent question answering, risk assessment, and clause verification. Overall, it improves the automation level and processing efficiency of insurance knowledge retrieval, conflict identification, and intelligent generation, providing unified, reliable, and efficient technical support for insurance knowledge management and intelligent decision-making. Attached Figure Description

[0051] Figure 1 This is an exemplary system architecture diagram of an insurance multi-source retrieval and consistency verification method disclosed in this application;

[0052] Figure 2 This is a flowchart illustrating a multi-source insurance retrieval and consistency verification method disclosed in this application;

[0053] Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in this application.

[0054] Explanation of reference numerals in the attached figures: 100, System architecture; 101, First terminal device; 102, Second terminal device; 103, Third terminal device; 104, Network; 105, Server; 301, Processor; 302, Communication bus; 303, User interface; 304, Network interface; 305, Memory. Detailed Implementation

[0055] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0056] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0057] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0058] Figure 1 An exemplary system architecture diagram is shown, illustrating an embodiment of an insurance multi-source retrieval and consistency verification method applicable to this application.

[0059] like Figure 1 As shown, the system architecture 100 may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0060] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0061] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0062] When terminals 101, 102, and 103 are hardware devices, video capture devices can also be installed on them. These video capture devices can be various devices capable of capturing video, such as cameras, sensors, etc. Users can use the video capture devices on terminals 101, 102, and 103 to capture video.

[0063] Server 105 can be a server that provides various services, such as a backend server for processing data displayed on terminal devices 101, 102, and 103. The backend server can analyze and process the received data and can feed back the processing results (such as recognition results) to the terminal devices.

[0064] It should be noted that a server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0065] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included. In particular, if the target data does not need to be obtained remotely, the above system architecture may exclude the network and include only terminal devices or servers.

[0066] Figure 2 This is a flowchart illustrating an insurance multi-source retrieval and consistency verification method according to an embodiment of this application. This method can be implemented using a computer program or a microcontroller. The computer program can be integrated into an application or run as a standalone utility application. The specific steps of the insurance multi-source retrieval and consistency verification method are described in detail below.

[0067] S201: Acquire heterogeneous document data in the insurance field, perform semantic parsing on the heterogeneous document data, and construct an insurance knowledge graph that includes business concepts and logical relationships between concepts.

[0068] For example, this step aims to address the "missing data associations" problem caused by the independent storage formats of multi-source heterogeneous data. Through deep semantic parsing and reconstruction of multi-source heterogeneous documents, the system maps discrete document data, originally stored at different physical addresses and lacking direct index associations, to a unified graph database storage space. This process achieves data format standardization and logical connection instantiation, building a clear logical underlying knowledge architecture for subsequent complex business queries and conflict detection.

[0069] In one possible implementation, heterogeneous document data in the insurance field is acquired, and semantic parsing is performed on the heterogeneous document data to construct an insurance knowledge graph containing business concepts and logical relationships between concepts. Specifically, this includes: based on a preset insurance domain ontology library, identifying the document types of the heterogeneous document data, and matching preset entity extraction templates according to the document types; using a semantic extraction model to perform structured extraction on the heterogeneous document data based on the entity extraction templates to obtain insurance business entities, wherein the entity extraction template defines target extraction fields corresponding to the document types, and the insurance business entities represent one or more of the following: product rights definition, underwriting risk control rules, industry compliance constraints, or historical business experience; identifying the business relationships between each insurance business entity, storing each insurance business entity as a node in a graph database, and mapping the business relationships as logical relationship edges connecting each node to form an insurance knowledge graph.

[0070] In this application embodiment, the insurance knowledge graph refers to a structured semantic network built on graph theory data structure, specifically used to describe complex business concepts and their interdependent relationships within the insurance industry. Essentially, it transforms unstructured text information into a set of "entity-relationship-entity" triples that can be processed by computers. For example, nodes in the graph represent specific "critical illness insurance products" or "hypertension," and edges between nodes represent specific business logic relationships such as "coverage," "exclusion," or "surcharge," thereby providing a reasonable knowledge base for subsequent conflict detection.

[0071] Specifically, to construct the aforementioned insurance knowledge graph, it is necessary to process raw data from diverse sources. The system will access heterogeneous document data from the insurance field, which typically includes product terms in PDF format, underwriting manuals in scanned image format, regulatory documents in HTML format, and non-standardized historical underwriting records. During processing, a pre-defined insurance domain ontology (i.e., a predefined schema layer describing the conceptual hierarchy and attribute constraints of the insurance industry) is used to perform feature scanning on the aforementioned documents, accurately identifying the specific document type of each document. Based on the identification results, the system will automatically call a pre-defined entity extraction template that matches the document type. This template is essentially a set of field extraction mapping rules or entity slot constraint configurations for a specific document structure, clearly specifying which key information should be extracted from this type of document.

[0072] Furthermore, a pre-trained semantic extraction model (e.g., a deep learning-based named entity recognition network or a large language model information extractor) is invoked to perform full-text scanning and structured extraction on heterogeneous document data according to the definition of the entity extraction template, thereby obtaining discrete insurance business entities. Depending on the document type, the extracted entities have distinct business attributes: entities extracted from product terms represent product benefit definitions (e.g., sum assured, waiting period); entities extracted from underwriting manuals represent underwriting risk control rules (e.g., BMI (Body Mass Index) restrictions, pre-existing condition rejection standards); entities extracted from regulatory documents represent industry compliance constraints (e.g., mandatory disclaimers); and entities extracted from past cases represent historical business experience (e.g., underwriting conclusions for similar medical histories). By using semantic dependency analysis or coreference resolution techniques, we can deeply mine and identify the business relationships between various insurance business entities (e.g., "Rule A" belongs to "Product B", "Term C" is subject to "Regulations D"). We can write these entities as vertices (Nodes) into a graph database (such as Neo4j or NebulaGraph) and map the identified business relationships as logical relationship edges connecting each vertex, thereby establishing an insurance knowledge graph with topological connectivity that includes node mapping indexes and edge attribute weights.

[0073] S202: Receive the business query request input by the user, perform a search in the insurance knowledge graph based on the business query request, sort the search results by relevance, and determine the candidate evidence set.

[0074] For example, this step forms an interactive bridge from the user's natural language input to the system's structured knowledge base. To address the complex semantics of insurance terms and rules, this step is not limited to traditional keyword matching, but leverages the topological advantages of knowledge graphs to execute a "funnel-like" filtering process from broad to precise. By combining semantic similarity calculation with deep graph structure reasoning, the system can quickly narrow down the search scope from massive amounts of data, eliminating noise data that is literally related but logically irrelevant, thereby locking in a precise and high-value set of candidate evidence for subsequent conflict detection.

[0075] In one possible implementation, a search is performed on the insurance knowledge graph based on the business query request, and the search results are ranked by relevance to determine a candidate evidence set. Specifically, this includes: calculating the vector similarity between the business query request and the text information corresponding to each node in the insurance knowledge graph using a semantic vector model, performing a first-stage coarse-sorting search, filtering relevant nodes based on the similarity ranking results, and determining an initial set of document fragments corresponding to the relevant nodes; parsing the key business elements in the business query request, performing a second-stage filtering search on the initial set of document fragments based on a preset business rule base, and retaining the first document fragment containing the key business elements; constructing a subgraph structure with the first document fragment and the business query request as nodes and the semantic relationships between nodes as edges, performing edge weight reasoning on the subgraph structure using a graph neural network model, performing a third-stage re-ranking, and selecting the second document fragment with a ranking score higher than a preset threshold as the candidate evidence set.

[0076] In this application embodiment, the Graph Neural Network (GNN) model refers to a deep learning architecture specifically designed for processing non-Euclidean graph structure data. It captures the complex topological dependencies between nodes and between nodes and edges in the graph through information transfer and aggregation mechanisms between nodes. For example, Graph Convolution Networks (GCN) or Graph Attention Networks (GAT) can be used to analyze the deep association strength between the "business query request" node and the "document fragment" node in the latent semantic space, thereby realizing nonlinear semantic mapping computation based on graph topology and including implicit association features between nodes.

[0077] Specifically, to accurately locate credentials that can effectively answer user questions from the massive knowledge graph, the system adopts a progressive three-stage processing strategy of "recall-filtering-ranking". The first stage, coarse ranking, uses a pre-trained semantic vector model (such as BERT or Sentence-BERT) to map the received business query requests and the text information stored in each node of the insurance knowledge graph into high-dimensional dense vectors. Semantic relevance is measured by calculating the cosine similarity between vectors. Based on the calculated similarity ranking results, relevant nodes are initially selected (i.e., the Top-N nodes with the closest semantics). Then, using the index mapping relationship in the graph, the initial set of document fragments corresponding to the relevant nodes is determined. To eliminate invalid fragments that are semantically related but lack core business conditions, the system uses natural language processing (NLP) to parse key business elements (such as specific entities like "critical illness name," "payout ratio," or "waiting period days") from the business query request. Based on this, it uses a pre-defined business rule base to perform a hard second-stage filtering retrieval on the initial set, directly eliminating fragments that do not contain essential key elements, retaining only the first document fragment containing the key business elements. To accurately assess the logical support of fragments for the query, the filtered first document fragment and the business query request are used as vertices, and connecting edges are established based on their semantic relationships, dynamically constructing a local subgraph structure. This subgraph is input into the aforementioned graph neural network model, which performs deep learning and edge weight inference on the edge features, outputting a precise score representing the "query-document" matching degree. Based on this, the system performs a third-stage re-ranking, extracting and selecting high-confidence fragments (i.e., second document fragments) with ranking scores higher than a preset threshold from the re-ranked list, ultimately determining them as the candidate evidence set for subsequent consistency verification.

[0078] Furthermore, to improve the feature extraction accuracy and weight allocation robustness of the graph neural network for specific semantic features in the insurance domain during the construction of the subgraph structure and inference, the system employs a specific-dimensional encoding design for the initial features of nodes and edges. For node features, not only are the semantic vectors of the text (extracted via BERT) included, but structural attribute features of the nodes are also integrated. For example, a "type one-hot encoding" is concatenated for each node to distinguish whether it is a "query entity," "term entity," or "numerical constraint entity"; simultaneously, "centrality features" (such as PageRank values) are introduced to characterize the importance of the node in the entire graph. For edge features, the system constructs multi-dimensional edge attribute vectors. In addition to the basic "semantic relevance" weights, the logical type of the edge is explicitly encoded (such as vectorized representations of relationships like "belongs to," "restricted," "excluded," and "includes"). During the inference process of the graph neural network, GAT based on a message-passing mechanism is used. The model not only aggregates the semantic features of neighboring nodes but also utilizes edge features as bias terms for calculating the attention coefficient. Specifically, when calculating the attention coefficient between node i and node j... At that time, the formula includes edge feature transformation terms. (in, This represents the feature vector of the edge attributes between node i and node j. (This represents the learnable weight matrix for the edge feature). Through training and optimization, when the edge feature vector represents a logical type such as "exclusion liability," even if the two connected nodes have a high cosine similarity in the text vectors, the corresponding edge feature transformation term will significantly reduce or reverse the final calculated attention weight (e.g., producing a negative attention coefficient or a weight close to zero). This mechanism achieves information suppression of specific semantic association paths at the mathematical operation level, thus demonstrating the logical negation effect of the exclusion liability clause on related entity concepts during feature aggregation.

[0079] S203: Perform logical comparison of each evidence fragment in the candidate evidence set, identify the business logic conflict relationship between any two evidence fragments in the candidate evidence set, and construct an evidence conflict set based on the business logic conflict relationship.

[0080] For example, this step addresses the "self-contradiction" problem in the business semantics of multi-source heterogeneous data. Since retrieved candidate evidence may originate from regulatory documents from different periods or different versions of business manuals, their conclusions often exhibit inherent inconsistencies. This step, through full pairwise logical verification, explicitly extracts the opposing relationships (such as compensation versus denial, compliance versus violation) between discrete evidence fragments, and constructs these contradictory relationships into a network-like conflict topology graph. This clearly defines the points of contention requiring adjudication, transforming a disordered collection of documents into a structured set with clearly defined logical adversarial relationships.

[0081] In one possible implementation, logical comparisons are performed on each evidence fragment in the candidate evidence set to identify business logic conflict relationships between any two evidence fragments in the candidate evidence set. An evidence conflict set is then constructed based on these business logic conflict relationships. Specifically, this includes: invoking a preset business rule reasoning engine to detect whether any two evidence fragments in the candidate evidence set are logically mutually exclusive in terms of underwriting conclusions or compensation liability; if logically mutually exclusive, a first type of conflict relationship is generated; invoking a historical case reasoning engine to compare similar situations between any two evidence fragments in the candidate evidence set based on a pre-stored historical underwriting case database to detect whether there are differences in business practices; if business practice differences exist, a second type of conflict relationship is generated; and based on the first and second type of conflict relationships, an evidence conflict set is constructed with evidence fragments as nodes and conflict relationships as edges.

[0082] In the embodiments of this application, the evidence conflict set refers to a graph-based data model specifically used for the structured representation and storage of contradictory states between multi-source data. It is usually constructed in the form of an undirected graph in graph theory, aiming to visualize abstract logical contradictions into a topological structure that can be traversed by a computer. For example, in this set, each vertex represents a specific clause fragment or case record, while the edges connecting the vertices represent irreconcilable conclusion oppositions or practical differences between the two. This set provides a globally visualized decision-making foundation for subsequent automated conflict resolution.

[0083] Specifically, to accurately identify and quantify inconsistencies in multi-source evidence, the system employs a dual verification mechanism combining deterministic logical rules and probabilistic case similarity. For explicit clause contradictions, a pre-defined business rule reasoning engine (such as a logic judge built on Drools or EasyRules) is invoked to perform a formal logical comparison of the content of any two evidence fragments in the candidate evidence set. This engine focuses on core business indicators, detecting whether the two fragments are logically mutually exclusive in key dimensions such as underwriting conclusions (e.g., "standard coverage" vs. "excluded coverage") or compensation liabilities (e.g., "full compensation" vs. "proportional compensation"), i.e., whether they yield diametrically opposed deterministic results under the same business premises. If logical mutual exclusivity exists, the system defines it as a rule-level blocking conflict (i.e., a violation of pre-defined absolute constraints) and generates a first-type conflict relationship accordingly.

[0084] To enable the business rule reasoning engine to handle unstructured text evidence, the system incorporates a Natural Language to Logical Expression (NL2Logic) conversion module. Before performing logical comparison, the system first uses dependency parsing trees to extract subject-verb-object structures and negation modifiers from the evidence fragments. For example, for the text "No compensation will be paid if a critical illness is diagnosed during the waiting period," the system extracts structured triples of <condition: during the waiting period>, <action: diagnosed with a critical illness>, and <conclusion: no compensation>. The system maps the extracted structured data to domain-specific language rules. For example, "no compensation" is mapped to Liability=0, and "full compensation" is mapped to Liability=100%. When performing mutual exclusion checks, the engine no longer performs simple text comparison but instead checks the satisfiability of symbolic logic. The system constructs a joint proposition containing the logical expressions of the two evidence fragments and checks whether the proposition has a solution. If, under the same preconditions (e.g., both are within the waiting period and both are diagnosed with a serious illness), the derived post-conclusions have no overlap in numerical ranges (e.g., one is 0 and the other is 100%), or are opposite in Boolean states, then they are considered logically mutually exclusive. This symbolic reasoning effectively identifies situations such as "greater than 180 days" and "no more than 6 months," which are literally different but logically compatible, thus avoiding false alarms.

[0085] Furthermore, to capture implicit practical biases, the system invokes the historical case reasoning engine and utilizes Case-Based Reasoning (CBR) technology. Based on a pre-stored historical underwriting case database (which stores a massive number of anonymized historical real underwriting cases and their processing results), it compares any two evidence fragments in the candidate evidence set for similar scenarios. This step aims to uncover the differences between "theoretical clauses" and "actual implementation," detecting any discrepancies in business practice (e.g., an outdated clause stipulates rejection, but many recent similar historical cases have passed underwriting). If a difference in business practice exists, the system defines it as an empirical statistical bias (i.e., a deviation from the distribution pattern of historical data) and generates a second type of conflict relationship accordingly. The system performs a conflict aggregation operation, summarizing and mapping the identified first and second type of conflict relationships to construct an evidence conflict set with evidence fragments as nodes and conflict relationships as edges, thus comprehensively depicting the evidence contradiction network in the current business query scenario.

[0086] S204: Obtain metadata information for each evidence fragment in the candidate evidence set, determine the source type and release time of each evidence fragment based on the metadata information, and calculate the evidence reliability score corresponding to each evidence fragment based on the source type and release time.

[0087] For example, this step constructs a two-dimensional evidence evaluation model that integrates "static authority" and "dynamic timeliness." Given the diverse and frequently updated nature of data sources in insurance business, the system no longer relies solely on text similarity for retrieval. Instead, it further mines the metadata value behind the data, mathematically modeling and quantifying the legal validity level of evidence (e.g., regulatory documents are superior to historical cases) and time decay characteristics (e.g., new regulations are superior to old regulations). This allows for the calculation of precise reliability quantification values ​​for each discrete piece of evidence, providing an objective numerical benchmark for identifying the most effective business documents in complex conflicts.

[0088] In one possible implementation, the source type and publication time of each evidence fragment are determined based on metadata information. An evidence reliability score is then calculated for each evidence fragment based on its source type and publication time. Specifically, this includes: identifying the source type corresponding to each evidence fragment; assigning a first authority level weight if the source type is a regulatory document; assigning a second authority level weight if the source type is product terms; assigning a third authority level weight if the source type is an underwriting manual; and assigning a fourth authority level weight if the source type is a historical case. The first authority level weight is greater than the second authority level weight, the second authority level weight is greater than the third authority level weight, and the third authority level weight is greater than the fourth authority level weight. The number of days between the publication time of each evidence fragment and the current date is calculated. An exponential decay function is used to calculate a timeliness correction coefficient corresponding to each evidence fragment based on the number of days. Finally, the authority level weights corresponding to each evidence fragment are weighted and corrected using these timeliness correction coefficients to obtain the evidence reliability score for each evidence fragment.

[0089] In this application embodiment, the evidence reliability score refers to a comprehensive numerical index used to quantify the reliability and priority of a specific data fragment in the current business scenario. Essentially, it transforms abstract background information of the data source into a weighted scalar that can be compared by a computer. For example, the score is usually between 0 and 1. The higher the score, the more the evidence fragment complies with current regulatory requirements or business specifications, and the higher the probability of being adopted when logical conflicts occur. This score is the core basis for the subsequent automated decision-making and conflict resolution of the system.

[0090] Specifically, to ensure that the evidence ultimately adopted meets both legal validity and effectiveness, the system first parses metadata to accurately identify the source type corresponding to each piece of evidence, and establishes a strict grading mechanism based on the business attributes of the insurance industry. The evidence is ranked from highest to lowest validity: if the source type is a regulatory document, it is assigned a first-level authority weight (e.g., 0.9); if the source type is product terms (i.e., insurance contracts, which are legally binding), it is assigned a second-level authority weight (e.g., 0.7); if the source type is an underwriting manual (i.e., internal operating instructions, which are operational standards), it is assigned a third-level authority weight (e.g., 0.5); if the source type is historical cases (experience data for reference only), it is assigned a fourth-level authority weight (e.g., 0.3). To ensure strict hierarchy, the system strictly limits the weight value of the first-level authority to be greater than that of the second-level authority, the second-level authority to be greater than that of the third-level authority, and the third-level authority to be greater than that of the fourth-level authority.

[0091] Furthermore, to prevent the reliance on outdated rules or clauses, the system incorporates a time dimension for dynamic correction. It reads the publication time from the metadata and calculates the number of days between the publication time of each piece of evidence and the current date. Using an exponential decay function, it calculates the timeliness correction coefficient y corresponding to each piece of evidence based on the interval t, for example, y=e -λt Where t is the interval in days, and λ is a preset decay rate constant (e.g., a value between 0.01 and 0.1, used to control the influence of time on the reliability score). The characteristic of this function is that as the interval in days increases, the correction coefficient exhibits a non-linear, rapid decreasing trend, thus performing weighted suppression processing on stale data. The system performs a weighted calculation, using each timeliness correction coefficient to weight the authority level weight corresponding to the evidence segment (usually through multiplication), thereby calculating the final evidence reliability score corresponding to each evidence segment.

[0092] S205: Based on the reliability scores of each piece of evidence, resolve the set of conflicting evidence, and select the target evidence fragment from the candidate evidence set according to the resolution results to form a consistent chain of evidence.

[0093] For example, this step is essentially an automated decision-making process based on quantitative indicators. Faced with complex situations such as potential inconsistencies between regulations and terms or conflicts between old and new rules within the candidate evidence set, the system uses the objective reliability score calculated in previous steps as the arbitration basis to perform a pruning operation on the conflict set, selecting the best and removing redundancy based on the reliability score. This process aims to eliminate noise and paradoxes within the data source from a logical perspective, retaining authoritative evidence with the highest validity and latest relevance. This transforms a messy and potentially contradictory initial retrieval set into a logically monotonous, non-exclusive chain of evidence, laying a solid logical foundation for subsequent high-quality text generation.

[0094] In one possible implementation, the evidence conflict set is resolved based on the reliability scores of each piece of evidence. Based on the resolution results, target evidence fragments are selected from the candidate evidence set to form a consistent evidence chain. Specifically, this includes: locating a first evidence fragment and a second evidence fragment in the evidence conflict set that have a business logic conflict relationship; comparing the first evidence reliability score corresponding to the first evidence fragment with the second evidence reliability score corresponding to the second evidence fragment; if the first evidence reliability score is greater than the second evidence reliability score, then marking the first evidence fragment as retained and the second evidence fragment as removed in the evidence conflict set; after traversing the evidence conflict set, extracting all evidence fragments not marked as removed as target evidence fragments, and splicing them according to the business logic hierarchy to form a consistent evidence chain.

[0095] In this embodiment of the application, a consistent evidence chain refers to an ordered sequence of information that has been logically cleaned and denoised. It is composed of multiple evidence fragments that are mutually compatible in business logic, do not have contradictions or conflicts, and have high credibility. For example, the evidence chain can be composed of "the latest regulatory provisions", "current product terms" and "underwriting details that comply with regulations" linked together in a logical order. Its function is to provide the generation model with a contextual data set that has been logically denoised and has monotonic consistency in business rules, so as to ensure that the final generated answer will not produce the illusion of "saying both compensation and no compensation".

[0096] Specifically, to select a unique subset of target evidence that meets a preset reliability threshold from the original search results that are logically mutually exclusive, the system initiates an automated resolution process. A full scan of the previously constructed evidence conflict set is performed to accurately locate the first and second evidence fragments (i.e., the two endpoints of the conflict edge) that have a business logic conflict relationship. The scoring data calculated in the previous step is retrieved, and the reliability score of the first evidence fragment is compared with the reliability score of the second evidence fragment. Following the principle of "higher reliability first," if the reliability score of the first evidence fragment is greater than that of the second evidence fragment, it indicates that the first evidence fragment is more authoritative or timely. In this case, the first evidence fragment is marked as retained (i.e., a candidate node in the consistency chain) in the evidence conflict set, and the second evidence fragment is marked as removed (i.e., marked as a redundant or invalid node).

[0097] It should be noted that during the resolution process based on evidence reliability scores, the system also includes an arbitration mechanism for specific conflict scenarios. Scenario 1: Equivalent Scoring Arbitration. When the evidence reliability scores of the first and second evidence fragments are completely equal (or the difference is less than a preset small threshold ε), the system will initiate a "conservatism principle" for judgment. Specifically, the system identifies whether the two fragments contain restrictive semantics such as "exclusion," "refusal to claim," or "exclusion," prioritizing the fragment with stronger restrictions (i.e., stricter risk control for the insurance company) or the fragment with the more recent publication time (even if the total scores are similar after calculating the timeliness coefficient). Scenario 2: Cyclic Conflict Detection. After constructing the evidence conflict set, the system runs a strongly connected component detection algorithm. If a cyclic dependency is found in the evidence conflict network (e.g., evidence A negates evidence B, evidence B negates evidence C, and evidence C negates evidence A), the system cannot resolve the conflict simply through pairwise comparisons. At this point, the system calculates the average confidence score of all nodes in the connected component, forcibly retains the node with the highest score, and cuts off all conflict edges emitted by that node, thereby breaking the cycle and transforming the graph structure into a directed acyclic graph, ensuring that the subsequent resolution process can converge and output a unique chain of consistent evidence.

[0098] Furthermore, once the system has continuously traversed the set of conflicting evidence, it means that all binary conflict pairs have been processed. At this point, the entire candidate pool is scanned, and all evidence fragments not marked as being removed (this includes not only those that won in the conflict but also those "neutral" high-quality fragments that never participated in any conflict) are extracted as target evidence fragments. Based on the natural order of business semantics (such as the order of "legal basis - terms and conditions - operational details"), these target evidence fragments are concatenated according to the business logic hierarchy to form a logically consistent chain of evidence.

[0099] S206: Input the business query request and the consistent evidence chain into the generation model to generate the answer text and source explanation information for the business query request.

[0100] For example, the consistent evidence chain is transformed into user-friendly natural language interactive text. Unlike traditional search engines that only return a list of documents, this step uses a generative model to extract semantic features from the text sequence in the evidence chain and perform autoregressive decoding to directly output a definitive conclusion for the query request. Simultaneously, through synchronously generated source tracing explanation information, a data mapping link is established from unstructured query input to structured source tracing result output, ensuring that users can verify the evidence at any time while obtaining the answer. By providing the original data index address, a verifiable data anchor is provided for the text content generated by the model, thereby ensuring the traceability of the output results and the transparency of the data source.

[0101] In one possible implementation, the business query request and the consistent evidence chain are input into the generation model to generate answer text and source explanation information for the business query request. Specifically, this includes: constructing a prompt word template, dividing the prompt word template into a role instruction area, a task description area, and a context reference area; filling the task description area with the business query request and the context reference area with the consistent evidence chain to construct input prompt information; inputting the input prompt information into a large language model, using the attention mechanism of the large language model to capture the semantic features of each target evidence fragment in the consistent evidence chain, and generating answer text; extracting key information fragments referenced in the answer text, and back-matching the original source of the key information fragments in the consistent evidence chain to generate source explanation information containing document names and clause locations.

[0102] In this application embodiment, the prompt word template refers to a text input framework with a predefined specific structure and prompts, which aims to transform unstructured natural language interactions into a sequence of instructions that is easier for large language models to understand and follow. It typically includes a system-level instruction area for setting model behavior patterns, a user input area for carrying specific user questions, and a background information area for providing external knowledge support. For example, a simple question like "Will it be compensated?" can be reconstructed into a composite instruction containing "Role setting: Senior underwriter", "Background basis: [Clause A]", and "Task: Answer based on background", thereby significantly improving the accuracy and standardization of the generated content.

[0103] Specifically, to achieve interpretable and verifiable intelligent question answering, the system first constructs a prompt word template. This template is not a simple text concatenation but employs structured engineering design, dividing the prompt word template into a role instruction area (used to pre-define the identity and output specifications of the "insurance business expert"), a task description area (used to place the specific problem to be solved), and a context reference area (used to place retrieved external knowledge). Then, a dynamic assembly process is executed, filling the task description area with the received user business query request, and simultaneously filling the context reference area with a high-confidence, consistent evidence chain obtained through the previous steps, thereby constructing input prompt information containing complete context.

[0104] Furthermore, the input prompts are fed into a large language model (such as a generative model based on the Transformer architecture). The model will then initiate a deep reasoning process, utilizing the self-attention mechanism of the large language model to automatically calculate the association weights between different tokens in the input sequence. This allows the model to capture the semantic features of each target evidence fragment in the consistent evidence chain when generating each word. Based on this contextual reference knowledge from external inputs rather than the potential parametric memory illusions within the model, accurate and logically consistent answer text is generated.

[0105] Furthermore, to address the issue of inaccurate matching of the original text due to synonym rewriting in the text generated by the large language model when generating source tracing explanation information, this application employs a sliding window matching algorithm based on semantic fingerprints. The system does not rely on precise string matching. Key information fragments in the generated answer are converted into semantic vector sequences. A sliding window of variable length is maintained on the original text of the consistent evidence chain. The semantic edit distance between the text within the sliding window and the key information fragments is calculated. This distance considers not only character insertion and deletion operations but also introduces a weighted penalty for synonym substitution (the penalty is extremely low if it is a synonym). When the semantic edit distance of the sliding window at a certain position is less than a preset threshold, it is determined to be a source hit. Simultaneously, the system also performs contextual integrity verification on the hit original evidence fragments. If the matched passage is located within a clause modified by transitional words such as "however" or "except," the system automatically expands the scope of the source tracing to include both the transitional word and its main clause in the source explanation information (e.g., "According to Article 5 of Clause A: ... [quoted portion], but note the preconditions: ..."). This prevents misinterpretation and ensures the legal rigor of the source information. In this way, the system accurately locates the source of the information and ultimately generates source explanation information containing the document name and clause location, which is presented along with the answer.

[0106] This embodiment also discloses an electronic device, referring to... Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0107] The communication bus 302 is used to enable communication between these components.

[0108] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0109] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0110] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0111] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory 305 may include a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a multi-source insurance retrieval and consistency verification method.

[0112] exist Figure 3In the electronic device shown, the user interface 303 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 301 can be used to call an application program stored in the memory 305 that provides an insurance multi-source retrieval and consistency verification method. When executed by one or more processors 301, the electronic device executes one or more methods as described in the above embodiments.

[0113] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0114] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0115] In some embodiments of this application, a computer-readable storage medium is provided, including instructions that, when executed on the electronic device, cause the electronic device to perform an insurance multi-source retrieval and consistency verification method according to an embodiment of this application.

[0116] In some embodiments of this application, a computer program product is also provided, which, when run on an electronic device, causes the electronic device to execute an insurance multi-source retrieval and consistency verification method according to an embodiment of this application.

[0117] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0118] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0119] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0120] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0121] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope of this application is defined by the claims.

Claims

1. A method for multi-source retrieval and consistency verification of insurance products, characterized in that, The method includes: Obtain heterogeneous document data in the insurance field, perform semantic parsing on the heterogeneous document data, and construct an insurance knowledge graph containing business concepts and logical relationships between concepts; Receive a business query request input by a user, perform a search in the insurance knowledge graph based on the business query request, sort the search results by relevance, and determine a candidate evidence set; Logical comparison is performed on each evidence fragment in the candidate evidence set to identify the business logic conflict relationship between any two evidence fragments in the candidate evidence set, and an evidence conflict set is constructed based on the business logic conflict relationship; Obtain metadata information of each evidence fragment in the candidate evidence set, determine the source type and release time of each evidence fragment based on the metadata information, and calculate the evidence reliability score corresponding to each evidence fragment based on the source type and the release time. Based on the reliability scores of each piece of evidence, the evidence conflict set is resolved, and the target evidence fragment is selected from the candidate evidence set according to the resolution results to form a consistent evidence chain. The business query request and the consistent evidence chain are input into the generation model to generate an answer text and source explanation information for the business query request. The step of logically comparing each evidence fragment in the candidate evidence set to identify the business logic conflict relationship between any two evidence fragments in the candidate evidence set, and constructing an evidence conflict set based on the business logic conflict relationship, specifically includes: The preset business rule reasoning engine is invoked to detect whether any two evidence fragments in the candidate evidence set are logically mutually exclusive in terms of underwriting conclusion or compensation liability. If they are logically mutually exclusive, a first type of conflict relationship is generated. The historical case reasoning engine is invoked to compare any two evidence fragments in the candidate evidence set with similar situations based on the pre-stored historical underwriting case library. If there are differences in business practices, a second type of conflict relationship is generated. Based on the first type of conflict relationship and the second type of conflict relationship, construct the evidence conflict set with evidence fragments as nodes and conflict relationships as edges; The process of resolving the evidence conflict set based on the reliability scores of each piece of evidence, and selecting target evidence fragments from the candidate evidence set based on the resolution results to form a consistent evidence chain, specifically includes: Locate the first and second evidence fragments in the evidence conflict set that have the business logic conflict relationship; Compare the first evidence reliability score corresponding to the first evidence fragment with the second evidence reliability score corresponding to the second evidence fragment; If the reliability score of the first piece of evidence is greater than that of the reliability score of the second piece of evidence, then the first piece of evidence is marked as retained in the evidence conflict set, and the second piece of evidence is marked as removed. After traversing the set of conflicting evidence, all evidence fragments not marked as to be removed are extracted as the target evidence fragments and spliced ​​together according to the business logic hierarchy to form the consistent evidence chain.

2. The method according to claim 1, characterized in that, The process of acquiring heterogeneous document data in the insurance field, performing semantic parsing on the heterogeneous document data, and constructing an insurance knowledge graph containing business concepts and logical relationships between concepts specifically includes: Based on a pre-defined insurance domain ontology library, the document type of the heterogeneous document data is identified, and a pre-defined entity extraction template is matched according to the document type. Using a semantic extraction model, the heterogeneous document data is structurally extracted based on the entity extraction template to obtain insurance business entities. The entity extraction template defines target extraction fields corresponding to the document type. The insurance business entities represent one or more of the following: product rights definition, underwriting risk control rules, industry compliance constraints, or historical business experience. Identify the business relationships between the insurance business entities, store each insurance business entity as a node in a graph database, and map the business relationships as logical relationship edges connecting each node to form the insurance knowledge graph.

3. The method according to claim 2, characterized in that, The process of searching the insurance knowledge graph based on the business query request and ranking the search results by relevance to determine the candidate evidence set specifically includes: The semantic vector model is used to calculate the vector similarity between the business query request and the text information corresponding to each node in the insurance knowledge graph. The first stage of coarse ranking retrieval is performed, and relevant nodes are selected based on the similarity ranking results. The initial set of document fragments corresponding to the relevant nodes is determined. The key business elements in the business query request are analyzed, and the initial document fragment set is filtered and retrieved in the second stage based on the preset business rule base, retaining the first document fragment containing the key business elements. A subgraph structure is constructed with the first document fragment and the business query request as nodes and the semantic association between nodes as edges. The subgraph structure is then subjected to edge weight inference using a graph neural network model. A third-stage re-sorting is performed, and the second document fragment with a sorting score higher than a preset threshold is selected as the candidate evidence set.

4. The method according to claim 1, characterized in that, The step of determining the source type and publication time of each evidence fragment based on the metadata information, and calculating the evidence reliability score corresponding to each evidence fragment based on the source type and publication time, specifically includes: Identify the source type corresponding to each of the evidence fragments. If the source type is a regulatory document, set a first authority level weight. If the source type is a product terms, set a second authority level weight. If the source type is an underwriting manual, set a third authority level weight. If the source type is a historical case, set a fourth authority level weight. The first authority level weight value is greater than the second authority level weight value, the second authority level weight value is greater than the third authority level weight value, and the third authority level weight value is greater than the fourth authority level weight value. Calculate the number of days between the release time of each of the aforementioned evidence fragments and the current date, and use the exponential decay function to calculate the timeliness correction coefficient corresponding to each of the aforementioned evidence fragments based on the number of days between the release time and the current date; By using the aforementioned timeliness correction coefficients, the authority level weights corresponding to the aforementioned evidence fragments are weighted and corrected to obtain the evidence reliability scores corresponding to the aforementioned evidence fragments.

5. The method according to claim 1, characterized in that, The step of inputting the business query request and the consistent evidence chain into the generation model to generate the answer text and source explanation information for the business query request specifically includes: Construct a prompt word template, and divide the prompt word template into a role instruction area, a task description area, and a context reference area; The business query request is filled into the task description area, the consistent evidence chain is filled into the context reference area, and input prompt information is constructed. The input prompt information is input into a large language model, and the attention mechanism of the large language model is used to capture the semantic features of each target evidence fragment in the consistent evidence chain to generate the answer text; Extract key information fragments referenced in the answer text, reverse match the original source of the key information fragments in the consistency evidence chain, and generate source explanation information including document name and clause location.

6. An electronic device, characterized in that, Including processor and memory; The memory is used to store computer program code, the computer program code including computer instructions, and the processor invokes the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-5.

7. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-5.

8. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-5.

Images