Product page information verification method, electronic device, and storage medium

Abstract

This application belongs to the field of product testing technology, and relates to a product page information verification method, electronic device, and storage medium. By acquiring original snapshot data of the product page, the verification is based on the page state during actual user operation, ensuring data authenticity and temporal consistency. In the data processing stage, a combination of rule parsing, parameter standardization, and semantic analysis is introduced to unify data with different expression granularities into a comparable semantic form, reducing errors caused by field differences and semantic inconsistencies. Based on this, snapshot data, policy underwriting data, and product factory configuration data are uniformly compared to achieve consistency verification of product display, user selection, and backend underwriting results, improving accuracy and coverage. Simultaneously, through timed processing and structured output, automation and result traceability are achieved, thereby improving the efficiency and accuracy of multi-source data verification.

Description

Technical Field

[0001] This application belongs to the field of product testing technology, specifically relating to a product page information verification method, electronic device, and storage medium. Background Technology

[0002] With the development of online insurance product sales, insurance products are typically displayed to users through product pages, allowing users to complete the insurance application process online. In this process, the content displayed on the product page, the parameters selected by the user, and the final generated policy underwriting data are located at different business stages, and their data sources, structures, and processing methods all differ.

[0003] In the prior art, the verification of insurance product-related data usually relies on manual methods to check the content displayed on the product page against the system processing results, or on verifying some key fields based on preset rules. However, in the process of implementing this application, the inventors found that the prior art has at least the following problems: (1) Data verification lacks an effective end-to-end consistency mechanism: The verification methods in the prior art are mostly concentrated on a single link, such as checking only the front-end displayed data or the back-end underwriting results. It is difficult to systematically verify the consistency between product page data, user selection behavior and back-end processing results, resulting in the difficulty in timely detection of data deviations across links. (2) Verification methods rely on manual or partial automation, with limited efficiency and coverage: Faced with diverse product configurations and user selection combinations, manual verification methods are inefficient and difficult to cover all business scenarios; rule-based automated verification usually only targets limited fields or fixed scenarios, with insufficient overall coverage, affecting the integrity of the verification. (3) Lack of effective recording and utilization of the actual data status when business occurs: Existing technologies usually verify based on preset data or post-event data, which is difficult to reflect the page display status and selection status when users actually operate. When the product configuration changes, the existing verification basis is easily invalidated, thus affecting the accuracy of the verification results.

[0004] Therefore, how to provide a unified verification method applicable to data from multiple stages to improve the effectiveness and coverage of data verification and enhance the reliability of verification results has become an urgent problem to be solved in this field. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a product page information verification method, electronic device, and storage medium to achieve end-to-end consistency verification of the original snapshot data and policy underwriting data of insurance product pages, thereby improving verification efficiency, coverage, and result accuracy.

[0006] To address the aforementioned technical problems, one technical solution adopted in this application is: providing a product page information verification method, the method comprising: acquiring original snapshot data of the product page and storing the original snapshot data in a preset verification database; extracting the original snapshot data from the verification database according to a preset timed scheduling strategy to obtain first target snapshot data; acquiring policy underwriting data and product factory configuration data based on the first target snapshot data; performing data processing operations on the first target snapshot data to obtain second target snapshot data; wherein, the data processing operations include rule parsing operations, parameter standardization operations, and semantic analysis operations based on a large language model; comparing the second target snapshot data, policy underwriting data, and product factory configuration data to obtain comparison results; and visualizing the comparison results to generate a comparison result output report.

[0007] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above-mentioned method.

[0008] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium that stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the above-mentioned method.

[0009] Unlike related technologies, this application provides a product page information verification method, electronic device, and storage medium. By acquiring the original snapshot data of the product page, the verification data originates from the page state at the moment of actual user operation, thus ensuring the authenticity and temporal consistency of the data foundation and providing a reliable basis for subsequent cross-system verification. In the data processing stage, a data standardization process combining rule-based processing, parameter standardization, and semantic analysis is introduced, enabling data with different expression granularities to be uniformly expressed at the same semantic level, thereby providing a consistent data foundation for subsequent comparisons. This processing method significantly reduces comparison errors caused by differences in field naming, expression methods, and semantic inconsistencies, improving the overall verification accuracy. Based on this, the processed snapshot data, policy underwriting data, and product factory configuration data are uniformly compared to achieve systematic verification of the consistency between product display, user selection, and backend underwriting results, thereby improving the accuracy and coverage of verification. Furthermore, through timed processing and structured output mechanisms, the verification process is automated and the results are traceable. Based on this, this application achieves consistency verification of multi-source data through a data processing method that combines rule parsing, parameter standardization, and semantic analysis, which has significant effects on improving verification efficiency, coverage, and result accuracy. Attached Figure Description

[0010] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0011] Figure 1 This is a flowchart of a product page information verification method provided in an embodiment of this application; Figure 2 This is a flowchart of a data processing operation provided in an embodiment of this application; Figure 3 This is a schematic diagram of the comparison result output report provided in the embodiments of this application; Figure 4 This is a data flow diagram illustrating a product page information verification method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application. It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, and all are within the protection scope of this application.

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more.

[0014] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application.

[0015] Please see Figure 1 , Figure 1 This is a flowchart of a product page information verification method provided in an embodiment of this application. For example... Figure 1 As shown, the method includes steps S1-S6: S1: Obtain the original snapshot data of the product page and store the original snapshot data into the preset verification database.

[0016] In the insurance product application process, when a user triggers a page transition, the front-end captures the current page state at the application stage (e.g., clicking the "Apply Now" button or before the payment redirection) using a pre-defined interceptor. This interceptor intercepts the page transition behavior through the `onFormGoNextEx` decorator function configured in the front-end script, thereby obtaining the real-time page state data at the moment the user's action is triggered. The original snapshot data refers to the set of page states automatically collected by the front-end system at the instant the user performs the application. This set of states includes at least the information currently displayed on the page and the form interaction data selected by the user. Specifically: the information currently displayed on the page corresponds to `words` data, representing the product display text content currently visible to the user, including but not limited to the product name, insurance plan name, and descriptions of each insurance liability; the form interaction data selected by the user corresponds to `form` data, representing the application parameters actually selected or filled in by the user on the current page, including but not limited to plan codes (`planCode`), addons, and structured input content such as the sum insured.

[0017] After data collection is completed, the front end calls the preset reporting interface reportApplyPolicyTrace to encapsulate the collected words data, form data and proposal_id (insurance application ID) into a unified data structure for reporting. The proposal_id is used to uniquely identify the business instance corresponding to the current insurance application behavior.

[0018] During the data encapsulation process, in order to improve the structured expression capability of the displayed data, the formatPolicyWords processing operation is performed on the liability information involved in the words, converting the list of liabilities on the page into a standardized Markdown structured text format. The "#" is used as a hierarchical identifier and "||" is used as a separator between liability name and liability limit, so that the liability information forms a parsable structured expression at the semantic level, so that the subsequent system can reliably extract liability name and payment amount information.

[0019] For example, the reported data structure format is as follows: {"planName":"Extended Private Outpatient Drug Purchase","planDetail":"# General Medical Insurance || Shared 6 million\n\n# Designated Disease Outpatient and Emergency Medical Insurance || Shared 6 million\n\n# Specific Disease and Rare Disease Medical Insurance || Shared 6 million\n\n# Proton and Heavy Ion Medical Insurance || Shared 6 million\n\n# Outpatient Specific Drug Expense Medical Insurance || Shared 6 million\n\n# Outpatient Common Drug Insurance || Shared 6 million\n\n# Routine Outpatient and Emergency Medical Insurance (Optional) || 3000 RMB\n\n# Critical Illness Insurance (Optional) || 10 / 300,000","params":{"subPlan":"Inpatient + Designated Outpatient"},"modx":"Full Payment","productName":"WeDoctor Children's Million Medical Insurance","insureRule":"# Insured Age || 0 days - 17 years old\n\n# Coverage period || 1 year (effective from 00:00 the day after the policy is purchased)\n\n# Payment period || 1 year (supports monthly payment / full payment)\n\n# Waiting period || 30 days (no waiting period for accidental injury)\nCritical illness insurance benefit (if applicable) 90 days\n\n# Cooling-off period || 15 days"}. The words data includes: planName (current protection plan name), planDetail (coverage information), productName (product name), and insureRule (insurance rules); the form data includes: params (parameters), subPlan (sub-plan), and modx (payment method). It should be noted that this example only provides a description of the reported data structure format and is not limited thereto; the specific format depends on the actual situation.

[0020] After completing the above data encapsulation, the system writes the original snapshot data as a complete business record into a pre-defined verification database. The verification database is a dedicated persistent storage structure used to store verification data from the insurance application process. It uses `proposal_id` as the primary key to associate verification-related data records generated at different stages of the same insurance application, and uniformly stores words, forms, and their corresponding structured processing results to support subsequent cross-system consistency verification based on the same business instance. Ultimately, the verification database forms insurance snapshot record data with `proposal_id` as the dimension, thus completing the process of collecting and persistently storing the original snapshot data.

[0021] For example, the database design for validation might look like this: Input dimensions: form, words, product_code / combo_code (product identification information). Status dimensions: validation_result (validation result status: pending validation, successful, failed), is_bug (defect marker), manual_check (manual review status). Traceability dimensions: proposal_id (policy application ID), endorsement_no (application number, used for renewal / amendment scenarios). Result dimension: validation_deta (comparison result).

[0022] By capturing the product page state the instant a user triggers the critical insurance application, and uniformly encapsulating and persistently storing the page display information and user selection parameters, the verification data accurately reflects the actual page state at the moment of application. This avoids data distortion caused by subsequent page updates or configuration changes, ensuring the temporal consistency and traceability of the data source. Simultaneously, by synchronously recording display text and structured form data and storing them in association using business primary keys, a complete mapping relationship is formed between data corresponding to the same insurance application behavior in the verification database. This provides a stable and consistent data foundation for subsequent cross-system data consistency verification, thereby improving the accuracy and reliability of the overall verification results.

[0023] S2: According to the preset timed scheduling strategy, the original snapshot data in the verification database is extracted to obtain the first target snapshot data.

[0024] The process involves extracting raw snapshot data from the verification database according to a preset timed scheduling strategy to obtain first target snapshot data. This includes: querying the verification result status in the verification database at preset intervals to obtain the target verification result status; obtaining target identification information corresponding to the target verification result status; extracting raw snapshot data corresponding to the target identification information from the verification database based on the target identification information; and obtaining the first target snapshot data based on the target identification information and the raw snapshot data.

[0025] The system is configured with a preset timed scheduling strategy. The timed scheduling strategy refers to a data scanning mechanism that is triggered periodically at fixed time intervals. The preset interval is a pre-configured execution cycle, such as triggering a scheduling task once every hour or other configurable time periods.

[0026] When each scheduled task is triggered, the system first performs a status query on the verification records stored in the verification database. The verification result status indicates the processing progress of the current snapshot data, and this status field distinguishes between different processing stages such as unprocessed, processing, or completed. In this embodiment, the system filters records in the "target verification result status" from all verification records. The target verification result status refers to a pending state that has not yet entered the verification process (i.e., validation_result is in a pending verification state), thus obtaining the data set corresponding to the target verification result status.

[0027] After obtaining the data set of the target verification result status, the system further extracts the corresponding target identification information. This target identification information is used to uniquely identify an insurance application record. In this embodiment, the target identification information is proposal_id, which is the unique application number, used to distinguish and associate different insurance application records.

[0028] After obtaining the target identification information, the system retrieves data from the verification database based on this identification information, extracting the original snapshot data that matches the proposal_id. The original snapshot data is a set of page state data stored in step S1, specifically including the front-end displayed information (words) and the user-selected parameters (form), thus ensuring that data under the same insurance application can be completely restored.

[0029] Finally, the system combines the target identifier information proposal_id with its corresponding original snapshot data (words and form) to form the first target snapshot data. This first target snapshot data represents the set of insurance application snapshot data to be processed, filtered from the verification database, and serves as input data for subsequent verification processes.

[0030] By employing a timed scheduling strategy to periodically scan and filter data in the verification database, the system can automatically identify verification records in an unprocessed state at preset intervals and accurately extract the corresponding original snapshot data based on unique identifiers, thereby achieving automated aggregation of data to be verified. This approach avoids the uncertainties caused by manual triggering or random sampling, ensuring a stable execution rhythm and controllable processing order in the data processing process. Simultaneously, by using the verification result status as the filtering criterion and combining it with target identifier information for data location, different insurance records can be effectively distinguished and accurately matched to their corresponding snapshot data sets, thus guaranteeing the completeness and accuracy of data extraction. Furthermore, this mechanism enables the periodic automatic advancement of verification tasks, improving overall data processing efficiency and providing a standardized input data foundation with a clear structure and consistent source for subsequent unified verification processes.

[0031] S3: Based on the first target snapshot data, obtain policy underwriting data and product factory configuration data.

[0032] After acquiring the first target snapshot data, the system first parses the corresponding target identifier information from the first target snapshot data, which serves as a unified index for subsequent cross-system data association. Based on this proposal_id, the system calls the policy underwriting data acquisition interface to query the backend underwriting system. Here, policy underwriting data refers to the structured policy result data generated by the core insurance system after completing the insurance application process. In this embodiment, the system obtains the basic policy information of the corresponding application by calling the getProposalInfoByProposalID interface, and further obtains the detailed coverage liability data and corresponding sum insured information under the policy through the getPolicyDutyLiabilityList interface, thereby obtaining the underwriting result set.

[0033] Simultaneously, the system searches for product identification information (including product_code and combo_code) based on the target identification information and initiates a query request to the product factory configuration center. The product factory configuration center is a business system used to maintain standard coverage plans and liability configuration rules for insurance products. In this embodiment, the corresponding product plan is located through the product identification information, and target plan data is filtered from the returned plan set. Then, the standard liability list information `saleConfigLiabilities` configured under that plan is further extracted. The product factory configuration data refers to the standardized coverage liability configuration set output by the product configuration center. This data defines the name and corresponding liability attributes of each coverage liability at the product plan level, describing the standard coverage structure of the product at the business design level.

[0034] Finally, the system will output the policy underwriting data obtained based on proposal_id and the product factory configuration data obtained based on product identification information, respectively, for subsequent consistency verification processing with the display information and user selection data in the first target snapshot data.

[0035] By leveraging the business identification information in the first target snapshot data, relevant data from the backend underwriting system and product configuration system for the same insurance application behavior are correlated and retrieved. This allows the system to obtain policy underwriting data reflecting the actual underwriting results and product factory configuration data reflecting the product's standard design rules, thereby constructing a multi-source data foundation covering both business execution results and product configuration sources. This approach enables data from different sources and business stages to be uniformly aggregated and correlated around the same insurance application identifier, providing comprehensive data support for subsequent consistency verification between product display information, user selection information, and underwriting results. Simultaneously, by synchronously incorporating underwriting data and product configuration data into the same verification process, the completeness of data sources and the comprehensiveness of comparison dimensions are improved, thereby enhancing the accuracy and reliability of cross-system data comparison.

[0036] S4: Perform data processing operations on the first target snapshot data to obtain the second target snapshot data; the data processing operations include rule parsing operations, parameter standardization operations, and semantic analysis operations based on a large language model.

[0037] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data processing operation provided in an embodiment of this application. For example... Figure 2 As shown, the data processing operation includes steps S41-S44: S41: Perform rule parsing on the first target snapshot data to obtain the first target processing data.

[0038] The process of performing rule parsing on the first target snapshot data to obtain the first target processing data includes: performing feature decomposition on the first target snapshot data using a preset script to obtain the feature-decomposed first target snapshot data; performing atomic splitting on the feature-decomposed first target snapshot data to obtain the first processing data; and performing rule normalization processing on the first processing data to obtain the first target processing data.

[0039] The pre-defined rule parsing script `process_userSelect` performs feature extraction on the composite expression fields in the first target snapshot data. Regular expression matching is used to parse the user selection parameter string and the insurance rule string to identify descriptive information such as payment period, coverage period, and payment method, thus obtaining the feature-decomposed first target snapshot data. After feature decomposition, the feature-decomposed first target snapshot data undergoes atomic splitting, further breaking down the composite expression fields into indivisible basic parameter fields, such as "collectAndInsurePeriod: "Pay for 20 years, insure for 30 years" is broken down into atomic field structures (collectPeriod: "20Y", insurePeriod: "30Y"), thus obtaining the first processed data. Subsequently, rule normalization processing is performed on the first processed data. The pre-defined process_rule rule function standardizes the field names and values, and uniformly replaces the synonyms in the front-end display or operation configuration with the system's standard field system. For example, multiple expressions such as "insured age", "insured's age", and "insured's age" are uniformly unified into the standard field "insured's age", thereby eliminating semantic differences caused by different configuration sources. Finally, the first target processed data with rule cleaning and semantic alignment is obtained.

[0040] S42: Perform parameter standardization on the first target snapshot data to obtain the second target processing data.

[0041] The process of standardizing parameters on the first target snapshot data to obtain the second target processing data includes: extracting keywords from the first target snapshot data to obtain target parameter information; and mapping the target parameter information to standard enumeration values ​​to obtain the second target processing data.

[0042] Based on the completed rule parsing process, the first target snapshot data undergoes parameter standardization mapping to transform natural language parameters into a system-computable standard enumeration encoding system. Specifically, firstly, keyword extraction processing is performed on the first target snapshot data to extract key business fields from the front-end display text and user-selected parameters, identifying core parameters such as payment method description, payment cycle description, and coverage period description to form target parameter information. Subsequently, standard enumeration value mapping processing is performed on the target parameter information to convert unstructured or natural language expressions into preset enumeration encoding values. For example, "annual payment," "pay annually," and "pay every year" are uniformly mapped to YEAR codes, and "one-time payment" and "lump-sum payment" are uniformly mapped to SINGLE codes. Corresponding numerical periodic information is also mapped to standard field values ​​(e.g., mapping "annual payment" to code 1), thereby converting the target parameter information into a system-unified standardized parameter structure to obtain the second target processing data.

[0043] By performing rule parsing and parameter standardization on the first target snapshot data, dual cleaning and unification of the original business data at both the semantic and structural levels were achieved. First, through feature decomposition, atomic splitting, and rule normalization, the complex expressions in the front-end display text and operational configurations were decomposed into independently computable standard field structures, eliminating synonyms, non-standard field naming, and redundant semantic differences, thereby significantly improving the consistency and parsability of the data structure. Second, by extracting key business parameters and mapping them to a preset standard enumeration system, natural language or unstructured user selection information was converted into a unified system encoding expression, achieving standardized alignment of parameter values ​​from different sources and with different expression forms, thereby improving the consistency and comparability of cross-system data interaction. Through these processes, the first target snapshot data possesses highly structured and unified encoding characteristics before entering the subsequent semantic analysis and multi-source verification processes, significantly reducing semantic ambiguity and mapping errors in subsequent processing, and improving the overall accuracy, stability, and engineering feasibility of data processing.

[0044] S43: Perform semantic analysis on the first target snapshot data to obtain the third target processing data.

[0045] The process involves performing semantic analysis on the first target snapshot data to obtain the third target processing data. This includes: acquiring standard responsibility list information corresponding to the first target snapshot data; identifying the first target snapshot data based on a preset large language model and the standard responsibility list information to obtain the second processing data; and performing semantic alignment processing on the second processing data based on the large language model to obtain the third target processing data.

[0046] Before performing semantic alignment processing on the second processed data based on the large language model to obtain the third target processed data, the method further includes: performing unified transformation processing on the second processed data to obtain transformed second processed data; verifying the transformed second processed data to obtain verification results; and when the verification results meet the preset range, performing semantic alignment processing on the second processed data based on the large language model to obtain the third target processed data.

[0047] Specifically, based on a large language model, semantic alignment processing is performed on the second-processed data to obtain the third-target-processed data. This includes: performing feature normalization processing on the second-processed data according to the large language model to obtain normalized second-processed data; calculating semantic spatial distance on the normalized second-processed data according to the large language model to obtain third-processed data; and performing conflict detection on the third-processed data according to the large language model to obtain the third-target-processed data.

[0048] First, obtain the standard liability list information `saleConfigLiabilities` corresponding to the first target snapshot data. The standard liability list information is the standardized underwriting configuration result obtained from the product configuration center interface. It contains the standard liability set `saleConfigLiabilities` under the current product plan. This liability set is structured according to the main insurance liability and the supplementary insurance liability, and is used to characterize the scope of coverage that can be executed on the actual underwriting side.

[0049] After obtaining the standard liability list information, semantic recognition processing is performed on the first target snapshot data using a pre-set large language model. The pre-set large language model is a semantic parsing model with natural language understanding and insurance semantic mapping capabilities. It constrains the output structure through prompt words, enabling it to identify the actual coverage liability information contained in the coverage plan text displayed on the front end. This allows for semantic parsing and preliminary classification of the user-displayed coverage content in the first target snapshot data. Specifically, it removes non-coverage attributes (including service, supplementary explanations, marketing descriptions, and other non-liability information) and extracts payment information related to actual insurance liability, thus obtaining the second processed data. The second processed data is the structured representation of coverage liability after preliminary semantic parsing by the large language model.

[0050] After obtaining the second-processed data, a unified transformation process is further performed to obtain the transformed second-processed data. This unified transformation process converts the different expression formats, unit systems, and semantically redundant structures in the second-processed data into a unified standard input format. Specifically, this includes standardizing the string representation of the liability names, uniformly converting monetary units (e.g., converting "ten thousand yuan" and "yuan" to basic monetary units), and standardizing the fields of the liability description structure. This ensures that the transformed second-processed data possesses a comparable, unified structural expression.

[0051] After the unified transformation process is completed, a verification process is performed on the transformed second-processed data to obtain the verification result. This verification process determines whether the currently parsed set of coverage liabilities meets preset constraints in terms of numerical range, liability type, and structural integrity. These preset constraints include, but are not limited to, constraints on the reasonable range of liability amounts, the legality of liability item enumeration, and the structural integrity of the primary and supplementary insurance policies.

[0052] When the verification result meets the preset range, it means that the current data has the validity basis to enter the semantic alignment stage, thereby triggering the subsequent semantic alignment processing flow based on the large language model.

[0053] After entering the semantic alignment processing stage, the second-processed data is first normalized based on the large language model to obtain normalized second-processed data. The core purpose of feature normalization is to transform the expressions of insurance liability from different sources into a unified semantic anchor structure. Specifically, this involves "de-decorating" marketing language, that is, deleting modifying words and redundant expressions, and retaining only the core semantic units of liability. For example, "medical protection for 120 specific diseases" is normalized to "specific diseases", and "critical illness care insurance benefit" is normalized to "critical illness insurance benefit", thus obtaining normalized second-processed data. This process allows the semantic expression to converge from natural language form to the standard liability semantic space. After feature normalization, the semantic space distance between the normalized second-processed data and the standard responsibility list information is calculated based on a large language model to obtain the third-processed data. It can be understood that the semantic space distance calculation is implemented through vector embedding or a deep semantic matching model, mapping different responsibility items to the same semantic vector space and calculating their semantic similarity or semantic overlap to determine the semantic consistency between the responsibility displayed on the front end and the standard responsibility on the back end, thus obtaining the third-processed data. For example, it identifies the high degree of overlap between "death liability benefit" and "death payment" in the semantic space, while also identifying the degree of coverage or offset between different expressions.

[0054] After obtaining the third-stage processing data, further conflict detection processing is performed based on the large language model to obtain the final third-stage target processing data. It can be understood that conflict detection is used to identify semantic conflicts in semantic expressions where the scope of responsibility expands or contracts. Specifically, it determines whether the scope of responsibility has shifted by identifying the semantic structure of qualifying words (such as "contains" and "does not contain," "limited to" and "includes," "extended" and "additional," etc.). Even if the numerical value or responsibility name is the same, as long as there is a semantic constraint conflict, it is judged as an abnormal alignment state, thus outputting the final verified third-stage target processing data.

[0055] Throughout the semantic alignment process, the large language model is used not only for text understanding but also to construct a semantic mapping rule system for insurance liabilities. This enables front-end marketing expressions, operational configuration descriptions, and back-end underwriting terminology to be aligned and compared within a unified semantic space, thus solving the problem that traditional rule-based mapping cannot cover complex marketing expressions. Simultaneously, by introducing standard liability list information as an alignment benchmark, the model output is always constrained by the actual underwriting structure, avoiding mismatches caused by semantic expansion.

[0056] By introducing a semantic analysis mechanism that integrates standard liability list information with a large language model, the system can perform deep semantic parsing and structured reconstruction of complex protection plan descriptions in the first target snapshot data. This transforms the originally marketing-oriented, semantically redundant, and difficult-to-compare content into a structured semantic expression centered on standard liability, thus obtaining a comparable data foundation consistent with the underwriting side. During this process, a unified transformation and pre-verification mechanism constrains the legality and reasonableness of the input data, effectively improving the reliability and stability of semantic alignment processing. Simultaneously, feature normalization and semantic space distance calculation based on the large language model achieve semantic mapping and similarity measurement of protection liability under different expression methods, significantly enhancing the accuracy of liability matching across expression forms. Furthermore, a conflict detection mechanism identifies implicit semantic deviations such as the expansion or contraction of liability scope, enabling the system to maintain accurate judgment of underwriting liability consistency even in complex marketing scenarios. Through these processes, a computable and alignable semantic bridge is established between the front-end displayed information and the back-end standard liability system, significantly improving the accuracy, robustness, and engineering feasibility of multi-source heterogeneous insurance data in the consistency verification process.

[0057] S44: Obtain the second target snapshot data based on the first target processing data, the second target processing data, and the third target processing data.

[0058] After acquiring the above three types of processed data, a multi-source data fusion processing operation is performed. The first target processed data is used as the structural skeleton data, the second target processed data is used as the parameter supplement layer data, and the third target processed data is used as the semantic verification layer data for superposition and fusion. Among them, the structural skeleton data is used to determine the basic field organization method of the insurance record, the parameter supplement layer data is used to fill the business parameters in the structural skeleton with standard encoding, and the semantic verification layer data is used to add semantic consistency annotation and verification results to the liability level field, thereby forming a multi-dimensional related data fusion structure, namely the second target snapshot data.

[0059] S5: Compare the second target snapshot data, policy underwriting data, and product factory configuration data to obtain the comparison results.

[0060] S6: Visualize the comparison results and generate a comparison result output report.

[0061] Before performing the comparison, the policy underwriting data and product factory configuration data are first processed through structured standardization to eliminate structural differences between different data sources and form a unified and comparable data representation format. This involves performing structured dimensionality reduction on the policy underwriting data, extracting the core field `riskList.dutyList` related to liability verification from the original complex data structure returned by the policy core interface, and removing extended fields, descriptive fields, and redundant business fields unrelated to liability verification, thus forming an underwriting liability data set containing only the "liability name - liability limit" mapping relationship. Simultaneously, the product factory configuration data undergoes field mapping and standardization transformation, aligning the `liabilities` field in the product configuration with the underwriting liability field through unified semantic mapping, and converting it into a standard liability structure `{"name": "liability name", "value": "liability limit"}` according to preset field specifications, ensuring a consistent data structure representation with the underwriting data.

[0062] After completing the above standardization process, the third target processing data in the second target snapshot data, the liability data of the standardized policy underwriting data, and the liability data of the standardized product factory configuration data are uniformly mapped to the same liability comparison space. A three-party liability comparison index structure is constructed using the liability name as the unique index key and the liability limit as the comparison attribute value. Based on the comparison index structure, a deterministic matching comparison operation is performed on a liability-by-liability dimension. By performing liability limit consistency verification on data items with the same liability name, liability comparison results are generated.

[0063] Secondly, based on the first target processing data obtained from rule parsing, the corresponding underwriting parameters are extracted from the policy underwriting data and converted into an expression form consistent with the first target processing data; by comparing the underwriting parameters and the first target processing data, the rule comparison results are obtained.

[0064] Secondly, based on the second target processing data obtained from parameter standardization, actual underwriting parameters are extracted from the policy underwriting data and subjected to unified enumeration mapping processing; by matching the second target processing data with the underwriting parameters item by item, it is determined whether the two are consistent, and the parameter comparison results are obtained.

[0065] After completing the above three types of comparisons, the results of responsibility comparison, rule comparison, and parameter comparison are summarized to generate comparison results. The comparison results are structured data sets used to characterize the consistency status of multi-source data, including at least: a set of consistent data items, representing data items that are completely matched between data sources; a set of differing data items, representing data items that are inconsistent; and difference description information corresponding to the differing data items, indicating the specific reasons for the inconsistency, including differences in responsibility names, differences in responsibility limits, rule non-compliance, or parameter inconsistency.

[0066] After obtaining the comparison results, the sets of consistent data items and the sets of differing data items in the comparison results are classified and processed. The consistent data items are regarded as the data set that passes the verification, and the differing data items are regarded as the data set that is abnormal. For the data set that is abnormal, the corresponding difference description information is further extracted, and the reasons for the difference are expressed in a structured way to form interpretable difference description data.

[0067] Subsequently, based on the preset report structure, the consistent data item set and the abnormal data set are organized and formatted to generate a structured table containing multi-source data comparison relationships. Each data item includes at least: liability name or parameter name, corresponding value of second target snapshot data, corresponding value of policy underwriting data, and corresponding value of product factory configuration data. Abnormal data items are marked to highlight inconsistent content.

[0068] Based on this, the structured tabular data is visualized and rendered to generate a comparison result output report (such as...). Figure 3 (As shown). It is understandable that the comparison result output report is used to intuitively display the data consistency of insurance products throughout the entire process from front-end display and user selection to back-end underwriting execution, and supports traceability analysis of abnormal data, thereby achieving visualized output and closed-loop management of multi-source data consistency verification results. It should be noted that... Figure 3The insurance application number is the aforementioned proposal_id, the follow-up status is the aforementioned verification result status, the inspection result is the aforementioned comparison result, the front-end reported data is the aforementioned first target snapshot data, and the inspection details are the specific content of the aforementioned comparison result.

[0069] By performing multi-dimensional automated comparisons and outputting results on a unified data structure, the relationship between front-end displayed data, user-selected parameters, and back-end underwriting data is transformed from a previously fragmented and difficult-to-verify state into a quantifiable and verifiable consistency determination process. Specifically, atomic-level comparison of underwriting rule parameters effectively identifies discrepancies between the front-end display and back-end underwriting in key parameters such as age range, payment method, and coverage period. Structured matching and difference detection of payment items and coverage information accurately pinpoints issues such as missing liability items, mapping errors, or inconsistent amounts, significantly improving the completeness and accuracy of verification. Furthermore, structured encapsulation and visualization of the comparison results present them with clearly defined differences, error causes, and matching relationships. This not only improves problem location efficiency but also enhances the traceability and analyzability of the verification process, achieving an automated closed-loop processing effect from data verification to problem discovery and result presentation.

[0070] The following will combine Figure 4 and one A specific example (taking a certain medical insurance product, "WeDoctor Children's Million Medical Insurance," as an example) is used to explain in detail the implementation process of the product page information verification method provided in this application.

[0071] When a user selects the "Extend Private Outpatient Drug Purchase" coverage plan on the front-end page and clicks the "Apply Now" button, triggering a page redirect, the front-end intercepts this operation using a pre-defined event handler (the `onFormGoNextEx` decorator function), collecting the current page state data the instant the user's action is triggered. The collected raw snapshot data includes: user-visible display information (words, such as product name, coverage plan name, and various liability descriptions) and the form parameters actually selected by the user (e.g., payment method "full payment," sub-plan "inpatient + designated outpatient," etc.). The coverage liability information is processed by the `formatPolicyWords` function and converted into Markdown structured text, such as "# General Medical Insurance || Shared 6 million," etc. Subsequently, the front-end calls the `reportApplyPolicyTrace` interface to encapsulate the aforementioned words data, form data, and `proposal_id`, and writes them to the validation database, thus forming raw snapshot data uniquely identified by `proposal_id`.

[0072] The system triggers a scheduled task according to a preset timed scheduling strategy (e.g., once per hour) to scan the validation database and filter out records with a validation_result of "to be validated". For each record to be processed, its proposal_id is extracted, and based on this identifier, the corresponding words and form data are retrieved from the database to construct the first target snapshot data (i.e., proposal_id + words + form), which serves as the input for subsequent processing.

[0073] The system uses the `proposal_id` from the first target snapshot data to call the backend underwriting system interface `getProposalInfoByProposalID` to obtain the underwriting information corresponding to the policy. It then further uses the `getPolicyDutyLiabilityList` interface to obtain the policy's coverage responsibilities and corresponding sum insured, forming the policy underwriting data. Simultaneously, the system calls the product factory configuration center interface based on product identification information (such as `product_code` and `combo_code`), matches the current protection plan "Extended Private External Drug Purchases" in the returned plan set, and extracts the standard liability list `saleConfigLiabilities` corresponding to this plan, forming the product factory configuration data.

[0074] Subsequently, data processing operations are performed on the first target snapshot data. For example, the `process_userSelect` script performs regular expression parsing on compound expressions such as "pay for 20 years, insure for 30 years," breaking them down into atomic fields such as `collectPeriod="20Y"` and `insurePeriod="30Y"`. The `process_rule` function then unifies fields such as "insured age" to "insured's age," resulting in the first target processed data. Another example is extracting keywords from text such as "full payment method" and mapping them to standard enumeration values ​​(e.g., `SINGLE`), resulting in the second target processed data. Yet another example is introducing a large language model to semantically parse the coverage text, removing non-coverage information and extracting coverage items such as "critical illness insurance" and "general medical insurance," combining this with product factory configuration data for semantic alignment. Through feature normalization, semantic space distance calculation, and conflict detection, the third target processed data is obtained. Finally, the first, second, and third target processed data are merged to form the second target snapshot data with a unified structure.

[0075] Next, the system standardizes the policy underwriting data and product factory configuration data, converting them into a unified structure of {"name":"liability name","value":"liability limit"}. Then, it aligns and compares the liability data in the second target snapshot data with the two types of data mentioned above. For example, it compares the "shared 6 million" displayed by the user with the "shared 6 million yuan" in the underwriting data, identifying an inconsistency in the amount expression. Simultaneously, it performs atomic-level comparisons of rule parameters (such as coverage period and payment method) and enumerated value consistency checks on user-selected parameters (such as payment mode). Finally, it generates a comparison result, which includes consistent data items (such as "general medical insurance benefit") and differing data items (such as "critical illness insurance benefit amount is inconsistent"), along with corresponding descriptions of the differences.

[0076] Finally, based on the comparison results, the system organizes the consistent and differing items in a structured manner, generating a comparison table containing liability names, front-end display values, coverage values, and configuration values, and identifies and explains the differences. Subsequently, the system visualizes the above data using a preset report template, generating a comparison result output report to intuitively demonstrate the consistency of the insurance application in front-end display, user selection, and back-end underwriting, thereby completing the complete process of the product page information verification method in this embodiment.

[0077] This application provides a product page information verification method. By constructing a full-link verification mechanism covering "configuration baseline—front-end display—user selection—back-end underwriting," it achieves automated verification of the consistency of multi-source data in insurance business. At the data acquisition level, it collects page snapshot data (including displayed text "words" and selected form parameters) at key points in the insurance application process, and structures and stores it in a database. This ensures the verification data has a true business timeline and traceability, preventing data distortion caused by dynamic page configuration changes from the source. At the data processing level, it sequentially performs rule parsing, parameter standardization, and semantic analysis on the snapshot data. This enables insurance rule fields to complete synonym mapping and normalization conversion, user selection parameters to complete enumeration and structured expression, and payment text to complete noise reduction and semantic normalization. This unifies the originally scattered and non-standard data into a comparable standard data base, significantly reducing the comparison complexity caused by cross-system field differences. At the semantic processing level, a semantic alignment mechanism based on a large language model is introduced to identify and normalize semantic discrepancies between marketing expressions and insurance terminology, effectively solving semantic inconsistency problems that traditional string-based or rule-based mapping methods struggle to cover. At the data comparison level, the processed snapshot data is jointly verified with backend underwriting data and product configuration data across multiple dimensions. Consistency checks are performed on underwriting rule parameters, user selection results, and liability payment items, achieving bidirectional verification of whether the displayed content accurately reflects the underwriting results and whether the configuration is correctly mapped to the user's visible layer. At the result output level, by structurally encapsulating and visually displaying discrepancies, precise location and traceable analysis of issues such as error types, liability item deviations, and inconsistent amounts are achieved. Based on this, this application significantly enhances the accuracy, automation, and problem location efficiency of cross-system data consistency verification while improving the verification coverage.

[0078] This application also provides an electronic device 100, please refer to... Figure 5 This document illustrates a hardware structure diagram of an electronic device 100 capable of performing the methods described in the above embodiments. The electronic device 100 includes: at least one processor 110; and a memory 120 communicatively connected to the at least one processor 110. Figure 5 Taking a processor 110 as an example, the memory 120 stores instructions executable by at least one processor 110. These instructions, when executed by at least one processor 110, enable the at least one processor 110 to perform the product page information verification method described in the above embodiment. The processor 110 and the memory 120 can be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0079] The memory 120, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the product page information verification method in the embodiments of this application. The processor 110 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 120, thereby implementing the product page information verification method of the above embodiments.

[0080] The memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computing device. Furthermore, the memory 120 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 120 may optionally include memory remotely located relative to the processor 110, and these remote memories may be connected to the computing device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0081] One or more modules are stored in memory 120 and, when executed by one or more processors 110, perform the product page information verification method of the above embodiment.

[0082] It should be noted that the electronic device 100 provided in this application embodiment may be a server, terminal device or cloud computing node with data processing and storage capabilities, which executes instructions through a processor to implement all or part of the steps of this method.

[0083] The above-described product can execute the method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in this embodiment can be found in the product page information verification method of the embodiments of this application.

[0084] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions. These instructions are executed by one or more processors to enable at least one processor to perform the product page information verification method described in the above embodiments. For example, the non-volatile computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0085] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by an electronic device, enable the electronic device to perform the product page information verification method in any of the above method embodiments.

[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A product page information verification method, characterized by, The method includes: Obtain the original snapshot data of the product page and store the original snapshot data into a preset verification database; According to the preset timed scheduling strategy, the original snapshot data in the verification database is extracted to obtain the first target snapshot data; Based on the first target snapshot data, obtain the policy underwriting data and product factory configuration data; The first target snapshot data is processed to obtain the second target snapshot data; wherein the data processing operations include rule parsing, parameter standardization, and semantic analysis based on a large language model. The second target snapshot data, the policy underwriting data, and the product factory configuration data are compared to obtain the comparison results. The comparison results are visualized to generate a comparison result output report.

2. The product page information verification method of claim 1, wherein The step of extracting the original snapshot data from the verification database according to a preset timed scheduling strategy to obtain the first target snapshot data includes: At preset intervals, the status of the verification results in the verification database is queried to obtain the status of the target verification result. Obtain target identification information corresponding to the target verification result status, and extract original snapshot data corresponding to the target identification information from the verification database based on the target identification information; The first target snapshot data is obtained based on the target identification information and the original snapshot data.

3. The product page information verification method of claim 1, wherein The step of performing data processing operations on the first target snapshot data to obtain the second target snapshot data includes: Perform the rule parsing operation on the first target snapshot data to obtain the first target processed data; The parameter standardization operation is performed on the first target snapshot data to obtain the second target processed data; Perform the semantic analysis operation on the first target snapshot data to obtain the third target processed data; The second target snapshot data is obtained based on the first target processing data, the second target processing data, and the third target processing data.

4. The product page information verification method according to claim 3, characterized in that, The step of performing the rule parsing operation on the first target snapshot data to obtain the first target processing data includes: The first target snapshot data is decomposed into features using a preset script to obtain the first target snapshot data after feature decomposition. The first target snapshot data after feature decomposition is atomically split to obtain the first processed data; The first processed data is subjected to rule normalization to obtain the first target processed data.

5. The product page information verification method according to claim 3, characterized in that, The step of performing the parameter normalization operation on the first target snapshot data to obtain the second target processed data includes: Keyword extraction is performed on the first target snapshot data to obtain target parameter information; The target parameter information is mapped using standard enumeration values ​​to obtain the second target processing data.

6. The product page information verification method according to claim 3, characterized in that, The semantic analysis operation performed on the first target snapshot data to obtain the third target processing data includes: Obtain the standard responsibility list information corresponding to the first target snapshot data; Based on the preset large language model and the standard responsibility list information, the first target snapshot data is identified to obtain the second processed data; Based on the large language model, semantic alignment processing is performed on the second processed data to obtain the third target processed data.

7. The product page information verification method according to claim 6, characterized in that, The step of performing semantic alignment processing on the second processed data based on the large language model to obtain the third target processed data includes: Based on the large language model, the second processed data is subjected to feature normalization to obtain normalized second processed data; Based on the large language model, semantic space distance is calculated on the normalized second processed data to obtain the third processed data; Based on the large language model, conflict detection is performed on the third processed data to obtain the third target processed data.

8. The product page information verification method according to claim 6, characterized in that, Before performing semantic alignment processing on the second processed data based on the large language model to obtain the third target processed data, the method further includes: The second processed data is subjected to a unified transformation process to obtain the transformed second processed data; The transformed second processed data is verified to obtain the verification result; When the verification result meets the preset range, the second processed data is semantically aligned based on the large language model to obtain the third target processed data.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method according to any one of claims 1-8.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions that, when executed by an electronic device, cause the electronic device to perform the method described in any one of claims 1-8.

Images