Assembly product configuration scheme generation method, device, equipment and medium

Abstract

The present application relates to the technical field of intelligent decision-making, and discloses a configuration scheme generation method, device, equipment and medium for component products, comprising: obtaining historical product data, extracting product element information, forming standard components and storing them in a component library; obtaining historical business data, generating a component association set and constructing a component combination analysis model; forming a component selection combination through a visual interface; generating component recommendation information based on the component selection combination and the component association set; processing the component selection combination to form a configuration scheme; performing double checking on the configuration scheme to generate a checking result; and publishing the configuration scheme when the checking result allows publication. The present application can be applied to medical financial insurance and other business scenarios, manages product clauses through standard componentization, realizes automatic recommendation and combination in combination with a component association relationship and a component combination analysis model, and reduces configuration conflicts and errors through double checking, thereby improving product configuration efficiency and accuracy.

Description

Technical Field

[0001] This invention relates to the field of intelligent decision-making technology, and in particular to a method, apparatus, device, and medium for generating configuration schemes for component products. Background Technology

[0002] In the field of healthcare finance and insurance, health insurance products typically consist of numerous terms and conditions, liability descriptions, premium factors, and additional agreements. These elements have long existed in the form of documents, tables, and scattered system configurations. Product design and maintenance heavily rely on manual compilation and experience-based judgment. Different versions of the terms and conditions, premium logic, and liability descriptions are often scattered across multiple data carriers, lacking a unified, structured expression. When adjustments to existing products or the development of new products are needed, relevant personnel must repeatedly consult historical data, re-examine the terms and conditions, and manually combine them, resulting in long product development cycles, repetitive work, and difficulty in creating reusable, structured product assets.

[0003] In the management of existing health insurance products, complex logical relationships often exist between clauses, liabilities, and supplementary agreements. For example, the effectiveness of certain liabilities depends on specific conditions, and the addition of certain supplementary content affects the overall premium structure. These relationships are usually implicit in documentation or personnel experience, lacking explicit and unified management methods. This easily leads to problems such as clause conflicts, logical inconsistencies, or pricing errors during product bundling or adjustments. Furthermore, due to the lack of systematic utilization of historical business data, these relationships are difficult to accurately summarize and continuously optimize, making product design quality highly dependent on human judgment.

[0004] Furthermore, traditional business systems typically configure and deploy insurance products as a whole, resulting in deep coupling between product content and the system. When product combinations, liability adjustments, or new coverage are needed based on market demands, system-level modifications and releases are often required, lacking flexible configuration capabilities. In the sales or design phases, it is also difficult to dynamically combine and instantly verify product terms according to specific needs. The system cannot automatically check the interrelationships and overall rationality of terms while generating product solutions, leading to inefficient product design processes and increasing the risk of introducing potential problems. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for generating configuration schemes for component products. This aims to address the technical problem that existing health insurance product management methods lack structured modeling and automated processing capabilities for product terms and their logical relationships, resulting in product combination, verification, and release processes that heavily rely on manual judgment, leading to low efficiency and susceptibility to errors.

[0006] To achieve the above objectives, the present invention provides a method for generating a configuration scheme for a component product, comprising: Acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library; Acquire historical business data, determine the relationships between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data; The standard components in the component library are displayed through a visual interface, and component selection instructions are received. Based on the component selection instructions, component selection combinations are formed. Based on the selected component combination and the associated component set, component recommendation information is generated through the component combination analysis model. Based on the component recommendation information and the component association set, the component selection and combination are processed to form a configuration scheme; The configuration scheme is first checked based on the component association set, and then a second check is performed on the configuration scheme through the component combination analysis model to generate the check results. When the inspection results indicate that publication is permitted, the configuration scheme is published.

[0007] Furthermore, to achieve the above objectives, the present invention provides a component product configuration scheme generation apparatus, comprising: The component modeling module is used to acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library. The association learning module is used to acquire historical business data, determine the association relationship between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data. The visualization configuration module is used to display the standard components in the component library through a visual interface and receive component selection instructions, and form component selection combinations based on the component selection instructions. The intelligent recommendation module is used to generate component recommendation information based on the component selection combination and the component association set through the component combination analysis model; The scheme assembly module is used to process the component selection and combination to form a configuration scheme based on the component recommendation information and the component association set; The dual verification module is used to perform a first check on the configuration scheme based on the component association set, and a second check on the configuration scheme through the component combination analysis model, and generate a check result; The release control module is used to release the configuration scheme when the inspection result indicates that release is allowed.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a component product configuration scheme generation program stored in the memory and executable on the processor, wherein when the component product configuration scheme generation program is executed by the processor, it implements the steps of the component product configuration scheme generation method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a configuration scheme generation program for a component product, wherein when the configuration scheme generation program for the component product is executed by a processor, it implements the steps of the configuration scheme generation method for the component product as described above.

[0010] Beneficial Effects: This invention relates to the field of intelligent decision-making technology, and discloses a method, apparatus, device, and medium for generating configuration schemes for component products. The method includes: acquiring historical product data and parsing and extracting product element information; converting the product element information into standard components and storing them in a component library; acquiring historical business data, determining the relationships between standard components to generate a component association set, and constructing a component combination analysis model; selecting standard components through a visual interface to form a component selection combination; generating component recommendation information based on the component selection combination and the component association set through the component combination analysis model; processing the component selection combination according to the component recommendation information to form a configuration scheme; performing a first check and a second check on the configuration scheme to generate check results; and publishing the configuration scheme when the check results indicate that publication is permitted. This invention can be applied to business scenarios such as medical, financial, and insurance. By managing product terms through standardized components, combining component relationships and a component combination analysis model to achieve automatic recommendation and combination, and reducing configuration conflicts and errors through dual checks, it improves the efficiency and accuracy of product configuration. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a component product configuration scheme generation method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the configuration scheme generation method for component products of the present invention; Figure 3 A schematic diagram of functional modules of a preferred embodiment of the configuration scheme generation device for component products of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The configuration scheme generation method for component products provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can obtain historical product data from the client, parse and extract product element information, transform the product element information into standard components and store them in a component library; obtain historical business data, determine the relationships between standard components to generate a component association set, and construct a component combination analysis model; select standard components through a visual interface to form a component selection combination; generate component recommendation information based on the component selection combination and component association set through the component combination analysis model; process the component selection combination according to the component recommendation information to form a configuration scheme; perform a first check and a second check on the configuration scheme to generate check results; and publish the configuration scheme when the check results indicate that it is allowed to be published. This invention can be applied to business scenarios such as medical, financial, and insurance. By managing product terms through standardized components, combining component relationships and component combination analysis models to achieve automatic recommendation and combination, and reducing configuration conflicts and errors through double checks, it improves the efficiency and accuracy of product configuration. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a separate server or a server cluster composed of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the method for generating configuration schemes for component products provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the configuration scheme generation method for component products proposed in this invention includes the following steps: S10, acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library; In this embodiment, acquiring historical product data refers to the process of collecting and compiling complete product-related information and records from various internal and external information systems of an enterprise. This data forms the original material basis for standardized product modeling and knowledge accumulation. The sources of historical product data are diverse, including the enterprise's internal product lifecycle management system, actuarial and pricing databases, archived electronic contract document libraries, product promotional materials retained by the marketing department, and product filing information databases reported to regulatory agencies. The physical form of the data encompasses unstructured text documents, such as insurance terms and conditions brochures and product actuarial reports stored in PDF or Word format; semi-structured tabular data, such as Excel files recording rates corresponding to different ages and genders; and partially structured database records, such as product codes, names, and effective dates stored in the product master data table. In the field of medical financial insurance, a typical set of historical product data might be a collection of complete terms and conditions, rate manuals, claims rules documents, and related actuarial assumption documents for all health insurance products currently on sale and discontinued by an insurance company over the past five years. In practice, this acquisition process can be achieved by writing a data extraction script to read from the file server periodically, by calling the application programming interface of the internal system to pull data in batches, or by establishing a secure data channel with the external data provider, thus ensuring the integrity and accessibility of the original data.

[0016] Parsing and processing historical product data involves converting raw data of varying formats and structures into a standardized intermediate representation that computer programs can uniformly understand and manipulate. This process aims to strip away the data's storage format and presentation style, extracting the underlying plain text content and basic logical structure. The specific implementation includes several sub-operations such as format recognition, content decoding, noise removal, and preliminary structuring. The system first needs to identify the file format or data stream protocol of the input data, calling the appropriate decoder based on the file extension, MIME type, or content signature. For example, it might use a PDF parsing library to extract text and metadata, a document processing library to read paragraphs and styles from Word documents, or a spreadsheet processing library to parse Excel cell data and formulas. For image text generated using OCR technology, additional error correction and formatting are required. Subsequently, the extracted raw text stream undergoes data cleaning, removing irrelevant formatting control characters, duplicate headers and footers, watermarks, and any potentially garbled characters. Furthermore, document layout analysis techniques can be applied to understand the visual and logical organization of documents. For example, deep learning-based document understanding models can be used to analyze page elements, identify logical blocks such as titles, chapters, paragraphs, list items, and tables, and reconstruct the hierarchical relationships between them, thereby providing a structured contextual framework for subsequent accurate location and extraction of specific business information.

[0017] Product element information extraction is the activity of automatically identifying and extracting the smallest units of information with independent business meaning from parsed and cleaned text content, such as those defining the core functions, applicable conditions, restrictive clauses, and key parameters of a product. Product element information is the basic semantic atom of a product. In the specific field of medical financial insurance, this element information directly corresponds to the core components of the insurance product, such as insurance liability, specifically described as hospitalization medical insurance benefits; the prerequisites or triggering conditions for the liability to take effect, such as the insured must be diagnosed by a hospital with a disease stipulated in the contract; exclusions or exclusions, such as no reimbursement for treatment of congenital diseases; and key numerical parameters that determine the scope of liability or cost, such as an annual reimbursement limit of one million RMB or a reimbursement rate of 70% for specific drugs. Extracting this information relies on information extraction techniques in natural language processing. A typical implementation is to build and apply a named entity recognition model optimized for financial insurance text. This model can formalize the element extraction task as a sequence labeling problem. The model's input is a sequence of segmented and vectorized text terms, and the output is the entity type label for each term, such as B-DUTY and I-DUTY labels for liability entities, and B-CONDITION labels for conditional entities. To closely integrate with the healthcare, finance, and insurance sectors, the model's training data must consist of a large volume of manually annotated corpora from these fields, precisely labeling liability, condition, exclusion, and numerical entities in various clauses. The model can be based on a pre-trained language representation model, such as a pre-trained BERT model on financial news and company report corpora as the encoder, followed by a bidirectional long short-term memory network layer to capture contextual features, and finally a conditional random field layer to output the globally optimal label sequence. Training this model requires preparing an annotated dataset, proportionally dividing it into training, validation, and test sets. Key parameters used during training include a learning rate (e.g., 5e-5), a batch size of 32, using the AdamW optimizer, and employing a cross-entropy loss function for multiple rounds of iterative optimization until the model's performance on the validation set stabilizes. In this way, the model learns to accurately locate and classify standardized product element information from complex insurance policy texts.

[0018] Transforming product element information into standard components is a data modeling process that encapsulates extracted raw business information, assigns it unified specifications, clarifies its boundaries, and establishes programmable interfaces. Standard components are product building blocks that are self-descriptive, independently manageable, version-controllable, and reusable. The core of the transformation operation is to map, organize, and enrich the extracted, discrete element information based on a predefined, formalized component data model, generating standardized instances that conform to this model. This component data model defines a series of attribute fields that each component must contain, such as a globally unique component identifier, which can be generated using a UUID version 4 algorithm; a semantically clear component name; an enumerated value representing the component type, such as basic information, core insurance liabilities, additional value-added services, fees, and pricing adjustment factors; a detailed and unambiguous functional description text; a set of applicable conditions and parameter constraints defined in the form of logical expressions or key-value pairs; an extensible attribute list for storing various configuration parameters and their default values; and metadata required for management, such as creation time, update time, and version number. For example, the information extracted from the text, "Provides critical illness diagnosis insurance, covering malignant tumors, with a coverage amount of 100% of the basic insurance amount in the contract," is transformed into a standard component with the identifier "COMP_CRITICAL_ILLNESS_01," type "Critical Illness Protection." The functional description field retains the semantics of the original text, the applicable conditions field is encoded as a structured logical judgment statement, and the parameter list explicitly records the "payout ratio" parameter value as 100%. This transformation can be achieved through a configurable rule mapping engine that loads a configuration file describing the correspondence between source element fields and target component model fields, as well as the transformation rules; alternatively, a template filling system can be designed to predefine structured filling templates for each type of component, and the system automatically fills the extracted element information into the corresponding slots of the template.

[0019] Storing standard components in a component library is the process of persistently storing generated, standardized component instances in a centralized storage system that supports efficient retrieval and management. The component library is the sole authoritative source and asset repository for all standard components. In system implementation, the component library is typically built on database technology, with its logical and physical structure specifically designed to support categorized storage, fast querying, relationship management, and version control of components. For example, different data tables or collections can be designed at the database level based on the component's functional type, storing basic information components, core responsibility components, value-added service components, and pricing factor components respectively. All attributes of each component, including its identifier, type, description, parameters, and metadata, are serialized into a specific data format (such as JSON or Protocol Buffer) and written to the corresponding location in the database. Simultaneously, to support efficient retrieval, multi-dimensional indexes are created for components; index keys can include component type, functional keywords, applicable population tags, related disease codes, etc. The component library management system is also responsible for maintaining the relationships between components, such as recording that component A is a necessary prerequisite for component B (dependency), or that component C and component D cannot appear in the same product simultaneously (mutual exclusion). Furthermore, the component library implements a strict version management strategy, generating a new version record with each component update while retaining historical versions for auditing and rollback. This ensures the integrity, consistency, and traceability of component assets throughout their entire lifecycle.

[0020] This embodiment systematically acquires historical product data scattered across various systems and automates format parsing, content cleaning, and structural analysis. This releases product information, originally confined to different format files and databases, into uniformly processable digital content. Based on this, natural language processing technology, particularly domain-optimized information extraction models, is used to accurately identify and separate product elements with independent business meaning from text, such as insurance liability, effective conditions, and key parameters. These discrete elements are then encapsulated and mapped according to a unified and rigorous data model, generating standard components with globally unique identifiers, clearly defined types, and structured attributes. This makes each product component a clearly defined, semantically clear, and independently manageable digital asset. Finally, these standard components are persistently stored in a specially designed, centralized component library that supports efficient retrieval and relationship management, achieving systematic accumulation, standardized organization, and asset-based management of core product knowledge.

[0021] S20, acquire historical business data, determine the association between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data; In this embodiment, acquiring historical business data refers to the process of collecting and integrating records and indicators related to the product's performance, operation, and customer interaction in a real market environment. This data reflects the actual application effects, combination patterns, and correlations between product components and customer characteristics in history. The sources of historical business data are broader and more dynamic than product data, encompassing the enterprise's core business systems, customer relationship management systems, claims processing systems, financial settlement systems, and marketing platforms. Data formats include highly structured transaction logs, policy information, and claims records, as well as semi-structured customer service logs, underwriting opinions, and unstructured customer feedback texts. In the field of medical finance and insurance, typical historical business data includes details of all effective policies, recording policyholder profile information such as age, gender, and occupation; a list of specific liability components included in the purchased products; and claims application records generated over time, detailing disease diagnosis, treatment costs, compensation amounts, and compensation conclusions. Furthermore, it may also include product sales channel data, surrender rate data, and market response rate data for different customer groups. These data collectively constitute the practical basis for analyzing the actual correlations between components and training predictive models.

[0022] Determining the relationships between standard components based on historical business data and standard components in the component library is a process of automatically discovering and defining how components work together, influence each other, or constrain each other through data analysis. The core of this process is to map abstract business data to specific standard components, and then statistically analyze their co-occurrence patterns and mutual exclusion rules. First, the system needs to parse the product composition information in historical business data. For example, a historical policy record, through its product codes or liability lists, is mapped to one or more corresponding standard components in the component library, thus forming historical product combination instances composed of standard components. Simultaneously, contextual information related to this combination instance is extracted, such as the characteristics of the customers who purchased the combination, the frequency of claims triggered by the combination during its lifecycle, and average claim costs. Next, a massive amount of historical component combination instances are analyzed. By calculating the frequency and conditional probability of different standard components co-occurring in all historical combinations, potential dependencies can be discovered. For example, when component A appears, component B has a very high probability of appearing simultaneously, which may mean that B is a common pairing or necessary supplement to A in actual sales. By analyzing component pairs that rarely or never appear together in a portfolio, and combining this with business logic (such as certain treatments being mutually exclusive in terms of terms), conflicting or mutually exclusive relationships can be identified. Furthermore, sequence pattern mining techniques can be used to analyze the order in which components are added or removed in multiple insurance purchases or product upgrades, thereby uncovering deeper evolutionary dependencies. All these relationships derived through data analysis, including dependencies, conflicts, and sequences, are formally defined as association rules that can be understood and executed by computers.

[0023] Generating a component association set involves structuring and persistently storing the various relationships between standard components identified in the above analysis, forming a rule-based knowledge base that can be queried and invoked by other systems. The component association set is not a simple list, but a structured collection containing metadata such as relationship type, relationship strength, applicable conditions, and confidence level. Each relationship record explicitly specifies the subject and object components of the relationship, defines the relationship type, and may include metrics such as support, confidence, or lift derived from historical data to quantify the strength of the relationship. For example, a record might indicate a strong dependency relationship between the "core responsibility component [hospitalization expense reimbursement]" and the "value-added service component [hospitalization advance payment service]," with a support of 15% and a confidence level of 82%. This set can be implemented using various data structures, such as storing it in a specific table in a relational database, where each row represents a relationship; or storing it in a graph database, with components as nodes and relationships as edges with attributes. Generating the component association set transforms the implicit business logic and compliance constraints previously hidden in historical data into explicit, manageable, and reusable structured knowledge assets.

[0024] Building a component combination analysis model based on historical business data refers to using historical business data as training samples and employing machine learning algorithms to construct a predictive or evaluative model capable of learning the complex mapping relationship between product component combinations and contextual features to a certain business outcome. The core objective of this model is to understand and predict the potential performance or risk of a specific component combination under given conditions. Building the model first requires feature engineering for model training. Samples are constructed from historical business data. The input features of each sample typically include two parts: first, combination features composed of standard components, such as a vector consisting of multiple component identifiers, using multi-hot encoding to indicate which components are selected; second, contextual features related to this combination, such as profile features like the buyer's age, gender, region, and occupation, as well as environmental features like sales channels and promotional activities. The sample's label or target value is the business outcome to be predicted. In the context of healthcare, finance, and insurance, this could be the subsequent claims rate, average payout amount, policy persistence rate, or a comprehensive risk score corresponding to the combination. The model itself can choose from various machine learning architectures. One effective architecture is a deep neural network. The model's input layer receives preprocessed and standardized combination feature vectors and contextual feature vectors. These features are first passed through an embedding layer. Especially for high-dimensional, sparse combined features, the embedding layer maps them to low-dimensional, dense vector representations, capturing the semantic relationships between components. Then, the embedded vectors are concatenated with other numerical or categorical context features and fed into several fully connected layers for non-linear transformation and feature abstraction. Batch normalization and Dropout techniques can be used in the intermediate layers of the network to improve training stability and prevent overfitting. The final output layer is designed according to the task. For regression tasks (such as predicting payout costs), a linear activation function can be used to output a continuous value; for classification tasks (such as predicting high / low risk), a Softmax function can be used to output a probability distribution. Model training is a supervised learning process. The constructed historical sample dataset needs to be divided into training, validation, and test sets. During training, optimization algorithms, such as Adam, are used. Forward propagation is used to calculate predicted values, and loss functions, such as mean squared error (for regression) or cross-entropy (for classification), are used to calculate the difference between the predicted values ​​and the true labels. Then, the gradient is calculated using the backpropagation algorithm to update the weight parameters in the network. Key training parameters include the initial learning rate, number of training epochs, batch size, and the dimension of the embedding vectors. During training, performance metrics are monitored on the validation set to determine when to stop training to avoid overfitting. The final trained model is able to capture deep, non-linear patterns of correlation between component combinations, customer characteristics, and business outcomes.

[0025] This embodiment systematically acquires historical business data reflecting the actual operational performance of the product and maps it to a standard component library, providing a real, practice-based data foundation for analysis. Utilizing data mining and statistical analysis techniques, it automatically discovers and quantifies dependencies, conflicts, and other relationships between standard components from massive historical component combination instances. This transforms implicit business logic, which previously relied on expert experience and may have been one-sided, into an explicit, data-driven, and quantifiable knowledge base of association rules—a component association set. This achieves an objective and systematic analysis and consolidation of the complex internal structure logic of the product. Simultaneously, based on the same historical business data, feature engineering is used to construct training samples containing component combination features and rich contextual features. Machine learning algorithms are then used to train a component combination analysis model, enabling the model to learn and internalize the complex, non-linear mapping patterns between specific product components and their application scenarios and the final business results.

[0026] S30, the standard components in the component library are displayed through a visual interface and component selection instructions are received, and a component selection combination is formed based on the component selection instructions; In this embodiment, displaying standard components in the component library through a visual interface refers to designing and presenting a graphical user interface panel. This panel presents the standard components stored in the component library, which have clear semantics and attributes, to product designers or configuration personnel in an intuitive, understandable, and operable manner. The core purpose of the display is to transform digitized component assets into interface elements that users can visually perceive and directly interact with. This is not merely a simple list, but rather an effective organization and visual encoding based on the inherent attributes of the components. For example, components belonging to different categories such as basic information, core responsibilities, value-added services, and adjustment factors can be placed in different visual areas or tabs on the interface according to their functional category attributes. Within each category, components can be further sorted according to alphabetical order of their names, frequency of use, or importance. Each standard component can be represented on the interface as an independent information card or an interactive graphical control. The card clearly presents the component's key identification information, such as the component icon, short name, type label, and a summary of one or two core functions. To achieve efficient searching, the visual interface typically integrates a search function, allowing users to enter keywords. The system then matches component names or descriptions in the component library in real time and highlights the results. It also provides filtering functionality based on component attributes, such as using checkboxes to filter components applicable to specific age groups or containing specific coverage liabilities. This organized presentation structures the vast component library into an easy-to-navigate and understand visual information space, reducing the cognitive load on users.

[0027] Receiving component selection instructions refers to the ability of a visual interface system to capture and recognize the user's explicit intention to select or manipulate standard components displayed on the interface. This is a crucial aspect of human-computer interaction, transforming the user's visual browsing into operational instructions that can be processed by the program. User-issued instructions can take many forms. A common method is clicking on a pointer device, where the user moves the cursor to an interface element representing a standard component and clicks; the interface logic captures the unique identifier of the target component corresponding to this click event. Another method is touch control on a touchscreen device, where the user directly touches the component graphic on the screen. Additionally, drag-and-drop operations are supported, allowing the user to click and drag a component graphic to a specific "selected area" or canvas on the interface. Checkbox mode is also a selection method; each component has a checkbox next to it, and the user expresses their selection by checking or dechecking. The system needs to monitor these interaction events in real time. When an event is triggered, the underlying event handling logic parses the event object, extracts the identifier information of the target component, binds the interaction type with the component identifier, and generates a structured selection instruction. This instruction is typically a data object containing the operation type, target component identifier, operation timestamp, and possible operation context information. For example, when a user clicks the component card representing "Malignant Tumor Inpatient Medical Expense Reimbursement," the system generates an instruction: {"action": "select", "component_id": "COMP_CANCER_INPATIENT_001", "timestamp": "...", "source_panel": "core_liability"}. The system maintains an instruction buffer or queue to record all user selections within a given time period.

[0028] The process of forming a component selection combination based on component selection instructions involves the system collecting, integrating, and structuring a series of discrete selection instructions issued by the user, ultimately generating a complete set of components representing the user's current configuration intent. This process is dynamic and continuously evolves with the input of user instructions. The system needs to maintain a session-level data structure reflecting the current selection state, typically an ordered set or list. Whenever a new component selection instruction is received, the system first determines its operation type. If it is a "select" or "add" instruction, the standard component identifier specified in the instruction is added to the current selection set, ensuring that the same component is not added repeatedly. If it is a "deselect" or "remove" instruction, the corresponding component identifier is removed from the current set. In drag-and-drop interaction mode, the spatial arrangement of components may be assigned business meaning, and the resulting selection combination may be an ordered list, not just an unordered set. The system needs to update and persist the intermediate state of this selection combination in real time, typically storing it in the client's memory or storing it on the server via session. The final component selection combination is a complete data entity that encapsulates the list of identifiers of all standard components explicitly selected by the user. In addition, this composite object may also include some generated metadata, such as the session ID, the composite snapshot time, and preliminary statistics calculated based on the selected components, such as the total number of selected components and the distribution of component types involved. This composite object provides explicit, machine-readable user input for the subsequent intelligent recommendation and solution assembly process.

[0029] This embodiment constructs a structured visual interface to display digital assets in the standard component library in a clearly categorized, information-clear, searchable, and filterable graphical manner. This allows users to intuitively understand the composition of a vast array of components and quickly locate target components, significantly reducing the cognitive threshold and search time for product configuration. The interface accurately captures user selection commands issued through various interaction modes such as clicking, dragging, and checking, and converts these interaction events into a command data stream containing target component identifiers that can be precisely processed by the computer in real time, achieving a lossless conversion from user intent to machine instructions. The system dynamically collects and integrates these continuous commands, maintains and generates a real-time updated, structured component selection combination data object. This object completely and accurately encapsulates all configuration choices made by the user in the current session, forming a clear, serializable task input that can be directly used for subsequent processing.

[0030] S40, Based on the selected component combination and the associated component set, component recommendation information is generated through the component combination analysis model; In this embodiment, generating component recommendation information based on component selection combinations and component association sets is a composite decision-making process integrating rule reasoning and intelligent prediction, aiming to intelligently supplement, optimize, and guide the user's current initial choices. This process begins with a deep analysis of the input information. The component selection combinations represent the user's explicit, current configuration intent, while the component association sets encapsulate the constraints and patterns between components mined from historical data. First, the system parses the current component selection combinations, identifying the specific standard components already included. Next, this combination is matched and logically validated against the component association sets in real time. The validation process traverses predefined rules in the association sets, such as dependencies and mutual exclusions. Through rule engine pattern matching, the system can identify "logical gaps" in the current combination due to the lack of necessary dependent components, and "rule conflicts" arising from the selection of mutually exclusive components. The output of this stage is a diagnostic result of the completeness and consistency of the current combination within the established rule framework.

[0031] Based on the above diagnosis, the system needs to invoke a pre-trained component combination analysis model to obtain data-driven insights and suggestions that go beyond explicit rules. At this point, structured input needs to be prepared for the model. The input data is typically a feature vector that integrates multiple information sources. This vector contains at least two core parts: first, a numerical representation of the current component selection combination, for example, using multi-hot encoding to convert the combination into a binary vector, where each dimension corresponds to a standard component in the component library, with 1 for selection and 0 otherwise; second, contextual information derived from the correlation set diagnosis, such as flags indicating missing dependencies or conflicts, or the encoding of the specific missing dependency component type. In healthcare, finance, and insurance scenarios, business context features related to this configuration may also be added, such as preset target customer profile encoding or the product's basic pricing level. This carefully constructed feature vector fully characterizes the "current configuration state" and its surrounding "business environment."

[0032] The core step in generating intelligent recommendations is processing and reasoning through the component composition analysis model to analyze the input feature vectors. The component composition analysis model used here is a predictive model trained on massive amounts of historical business data. Internally, it has learned the complex mapping relationships between product component combinations and market performance, risk levels, or other business indicators. After receiving the feature vectors, the model's internal multi-layered nonlinear transformation structure begins to operate. Taking a deep neural network as an example, the input features first pass through an embedding layer, converting high-dimensional sparse component encodings into low-dimensional dense semantic vectors. This process captures the potential similarities between components. Subsequently, these vectors are concatenated with other features and then processed through multiple fully connected layers for information abstraction and fusion. Each layer may use activation functions such as ReLU to introduce nonlinearity. The final output layer of the model is designed according to the task objective. For component recommendation tasks, the output can be designed as a "recommendation score" or "association strength probability" for each standard component in the component library that is not currently selected by the user. This score quantifies the estimated degree to which adding the component will bring business value improvement (such as increasing product attractiveness or optimizing risk portfolio) given the current combination and context. The model uses the complex patterns contained in its parameter matrix to reason from the "current state" to the "potential optimization direction".

[0033] Generating component recommendation information involves integrating, interpreting, and encapsulating the raw scoring data output by the model with the results of previous rule-based diagnostics to form guiding information that can be understood by users or directly utilized by downstream systems. This process is not a simple sorting. The system first performs post-processing on the model's output according to a preset strategy. For example, a confidence threshold can be set to retain only components with a recommendation score higher than that threshold; or a Top-K strategy can be used to select the K components with the highest scores. More importantly, data-driven recommendations need to be organically integrated with rule-based diagnostics. For example, "missing necessary dependent components" identified by the rule engine can be included in the recommendation list with high priority and mandatory explanations. For components recommended by the model, the system can generate brief recommendation reasons based on association sets and internal interpretability analysis of the model, such as "This component often pairs well with your selected component A, and historical data shows that it can improve customer satisfaction." Finally, all this information—including the list of suggested new components, conflicting components to be removed or replaced, and the source and reason for each suggestion—is structured into a unified recommendation information object. This object may be in a format such as JSON and explicitly contains fields such as recommendation type, target component ID, confidence level, and recommendation basis, thereby completing the transformation from intelligent analysis to actionable suggestions.

[0034] The engineering practices for preparing input feature vectors for component composition analysis models can be diverse. For encoding component compositions, besides multi-hot encoding, when the component library is extremely large, hashing techniques can be used for dimensionality reduction, or unsupervised methods such as autoencoders can be used to learn low-dimensional representations of components before aggregating the representation vectors of components within the composition. Contextual information diagnosed from association sets can be transformed into numerical features or embedding vectors. For example, the categorical variable "missing dependency type" can be transformed into a vector using a separate embedding table. In financial insurance scenarios, business context features such as "target channel" or "product type" also require similar encoding. All these feature vectors need to be standardized or normalized before being fed into the model to ensure the stability and convergence speed of model training. The feature engineering process can be encapsulated as a reusable data preprocessing pipeline.

[0035] The architecture and training strategy of the component combinatorial analysis model can be adjusted according to the requirements of recommendation accuracy and real-time performance. Besides standard deep neural networks, model structures specifically designed for ensemble data, such as the DeepSets model, can be applied. This model processes component sets through symmetric functions, ensuring the order independence of the combinations. For scenarios aiming to capture the interaction effects between components, the DeepFM model, combining a multilayer perceptron and a factorization machine, can be used. The model's training objective needs careful design. One approach is to construct historical successful product combinations as positive samples, randomly remove some components as input, and use the removed components as the target to be predicted, thereby training the model to learn how to complete the combinations. Another approach is to use a reinforcement learning framework, treating the recommendation components as a sequential decision-making process, and using the commercial return of the final product as the reward to train the recommendation strategy. During training, the balance between positive and negative samples is crucial; negative sampling techniques can be used to sample negative components from historical data that have never appeared simultaneously with the current combination. Hyperparameter optimization can use grid search or Bayesian optimization to automatically find the optimal learning rate, batch size, network depth, and number of hidden units.

[0036] This embodiment analyzes the user's current component selection combination in real time and performs automated rule verification using a pre-built set of component associations. This allows for immediate diagnosis of deficiencies in the logical completeness and consistency of the configuration scheme, such as missing necessary dependencies or hidden conflicts, providing clear rule-based correction guidance. Furthermore, by transforming the current combination state, rule diagnosis results, and business context into structured feature vectors and inputting them into a trained component combination analysis model for inference, data-driven intelligent analysis is introduced to predict which unselected components can significantly improve the overall value of the combination or reduce potential risks. Finally, by combining the hard constraints of rule verification with the flexible suggestions of model inference, a component recommendation information package is generated, including specific recommended components, optimization reasons, and confidence levels. This process represents a leap from passively responding to user selections to proactively providing intelligent and personalized configuration suggestions, deeply integrating human experience with data intelligence, and greatly improving the rationality of product configuration, innovation efficiency, and the quality of the final output solution.

[0037] S50, based on the component recommendation information and the component association set, process the component selection and combination to form a configuration scheme; In this embodiment, the component selection combination represents the user's original intent set on the interactive interface, the component recommendation information provides a set of optimization suggestions based on rules and models, and the component association set carries the underlying business logic that constrains how these elements are combined. The processing begins with the fusion of inputs. The system first parses the component recommendation information, extracting specific suggested operations, such as explicitly specifying the list of recommended components to be added, and identifying existing components to be removed or replaced. Simultaneously, the system reads the current component selection combination, using it as the basic blueprint for processing. A core operation is merging the recommended components with the original selection combination. This merging is not a simple addition of sets, but rather based on a certain strategy. The strategy can be designed to automatically adopt all high-confidence recommended components, or it can be designed to present the recommendation list to the user for confirmation before merging. After merging, an expanded temporary candidate component set containing the original intent and intelligent suggestions is generated; this set is the starting point for subsequent in-depth processing.

[0038] Next, the system performs a rigorous logical completeness and consistency check on this temporary candidate component set based on the business rules defined in the component association set. The check is bidirectional. On one hand, the system checks whether the set satisfies all necessary dependencies; that is, if component A is selected, does component B, which it depends on, also exist in the set? If a missing component is found, it is recorded as a "missing dependent component." On the other hand, the system scans the set for component pairs that violate mutual exclusion rules; that is, whether two components that are incompatible according to the association set are selected simultaneously. If found, they are recorded as a "conflicting component pair." This check process transforms implicit business constraints into an explicit diagnostic report for the current component set.

[0039] Based on the above verification and diagnostic results, the system needs to perform conflict resolution and dependency completion operations to eliminate logical contradictions and fill structural defects in the solution, thereby determining a logically pure and complete set of components. Conflict resolution needs to follow a preset strategy. One basic strategy is a priority strategy, for example, stipulating that the components originally selected by the user have higher priority than the recommended components. When a conflict occurs, the user-selected components are retained first, while conflicting components from the recommendation information are removed or marked. Another strategy may be based on the business value or risk score of the components. For identified missing dependency components, the system needs to automatically add them to the set. These added components are usually obtained directly from the associated set or selected from a preset dependency component library. After completing conflict resolution and dependency completion, the resulting set of components is called the final valid set of components. This set no longer has rule conflicts and satisfies all necessary dependency conditions, making it a logically self-consistent product feature package.

[0040] Ultimately, the logically valid set of components needs to be instantiated into a concrete, publishable, and executable configuration scheme according to the structured expression specifications of the specific product domain. This is typically achieved through a pre-defined product structure template. This template defines the overall framework, hierarchical relationships, and attribute slots for each component. For example, in an insurance product, the template might define top-level modules such as "Basic Product Information," "Insurance Liability Section," "Exclusions Section," "Underwriting Rules," "Claims Rules," and "Rate Table." The system maps and populates each standard component in the final valid set into the corresponding node or module of the product structure template based on its type and attributes. A "Hospitalization Expense Compensation" component will be populated into the "Medical Expense Compensation" sub-node under "Insurance Liability Section," with its specific insured amount, reimbursement ratio, and other parameters written into the node's attributes. This process involves not only simple placement but also precise matching of component parameters with template fields and templated expression of relationships between components. After mapping and filling, the generated structured object is a complete configuration scheme. It contains all the necessary functional components and has the complete organizational form and parameter details required by the product. It can be regarded as a digital product prototype to be released.

[0041] This implementation systematically integrates the user's initial component selections with intelligent component recommendation information to form a richer temporary candidate set, providing a more comprehensive material foundation for solution optimization. Subsequently, strictly adhering to the business rules inherent in the component association set, the candidate set undergoes automated dependency completeness checks and mutual exclusion conflict scanning. This accurately identifies logical structural deficiencies and contradictions in the solution, exposing and quantifying potential business rule risks in advance. Based on explicit strategies, conflict resolution and dependency completion operations are automatically executed, correcting problematic candidate sets into a logically self-consistent final valid component set that conforms to all established constraints without manual intervention. Finally, by mapping and populating the valid component set into a preset product structure template, a standardized configuration solution with a complete structure, standardized format, and all necessary details is automatically generated.

[0042] S60, perform a first check on the configuration scheme based on the component association set, and perform a second check on the configuration scheme through the component combination analysis model to generate check results; In this embodiment, the first check on the configuration scheme based on the component association set is a process of automating and deterministically validating the scheme content using pre-defined structured business rules. The goal of the first check is to ensure that the configuration scheme conforms to all predefined and explicit business logic and compliance constraints. The check process begins by extracting all included standard components and their organizational structure information from the configuration scheme, forming a data snapshot that can be processed by the rule engine. This snapshot clearly reflects which components constitute the scheme and their positions and relationships within the product framework. Subsequently, the system loads all constraint rules defined in the component association set. These rules typically exist in the form of logical conditional statements, such as mutual exclusion rules describing the inability of two components to coexist, or dependency rules describing the necessity of one component for the existence of another. The check engine takes the data snapshot of the configuration scheme as factual input and evaluates the satisfaction of each rule under the current facts. The evaluation process involves pattern matching and logical judgment. When the engine finds that the condition of a rule is satisfied but the conclusion is violated, it identifies a rule violation instance. For example, if a rule stipulates that "component A and component B are mutually exclusive," and the configuration scheme includes both component A and component B, the engine will generate a violation record. The output of the first check is a clear list of compliance issues, each item of which details the type of rule violated, the specific component involved, and the specific context within the configuration scheme. These issues directly correspond to deficiencies in the scheme at the level of known, deterministic business rules.

[0043] The second check of a configuration scheme using a component portfolio analysis model is a process of intelligently and evaluatively analyzing the scheme using a data-driven predictive model. The goal of this second check is to identify potential problems or optimization opportunities in the configuration scheme regarding uncertain indicators such as risk, market adaptability, and profitability. The check first requires converting the configuration scheme into a numerical feature representation that the component portfolio analysis model can process. This conversion relies on feature engineering, typically involving extracting identifiers for all standard components in the configuration scheme and encoding them into a high-dimensional sparse vector. For example, using multi-hot encoding, each dimension of the vector corresponds to a component in the component library, with a value of 1 for presence and 0 for absence. Simultaneously, contextual features related to the scheme need to be extracted, such as the product's target sales channels, preset price range, and demographic characteristics of the target customer group. All these features are combined into a structured feature vector. This feature vector is then input into a pre-trained component portfolio analysis model. This model has learned the complex non-linear mapping relationship between product features and various business outcomes (such as claims ratio, surrender rate, and market share) through historical business data. The model typically contains multiple layers of neural networks. Input features first pass through an embedding layer to convert discrete component identifiers into dense vector representations. These vectors then undergo nonlinear transformations and information fusion through multiple fully connected layers, finally generating one or more predicted values ​​through the output layer. In healthcare financial insurance scenarios, the model's output might include the estimated payout ratio of the configuration plan, the expected new single-order growth rate, or a comprehensive risk score. The system compares these predicted values ​​with preset thresholds or benchmarks to determine whether the plan's performance is acceptable in the corresponding dimensions. If a predicted value exceeds the acceptable range, the system generates a model evaluation warning. The output of the second check is a set of evaluation information based on data-driven predictions, which reveals potential future performance issues of the plan based on historical patterns and empirical rules.

[0044] Generating inspection results involves systematically integrating, analyzing, and formatting the list of definitive compliance issues from the first inspection with the predictive assessment information from the second inspection, ultimately forming a unified, comprehensive, and actionable review report. This process is not a mechanical merging; it involves the correlation, prioritization, and interpretation of information. The system may assign a priority level or severity label to each identified issue based on its nature, severity, and the scope of business impact. For example, a violation of mandatory compliance rules might be marked as "fatal," while a risk slightly exceeding a threshold predicted by the model might be marked as "warning." Simultaneously, the system attempts to provide specific background information and corrective suggestions for each issue. For rule violation issues, suggestions may directly point to components that need to be added, removed, or replaced. For model warning issues, suggestions may require more in-depth analysis, such as a suggestion like, "Due to the historical co-occurrence of liability combinations X and Y leading to high risk, it is recommended to adjust the sum assured or increase the deductible." All this information is organized into a structured data object, typically containing the overall status of the inspection, an overview of issues, and detailed information for each issue. The final inspection results can be presented to product designers or approvers as decision support materials, or they can be input as structured data into subsequent automated workflows, such as triggering automatic correction of the solution or entering the manual review queue.

[0045] The implementation of the rule engine for the first check can be selected based on the complexity and dynamism of the rules. For environments with a stable number of rules and simple logic, a set of validation functions can be implemented directly using a programming language. When rules need frequent updates by business personnel or the logic is very complex, a separate business rule management system should be integrated. For example, the Drools rule engine can be used, where each rule in the component association set is written as a DRL file. During the check, the configuration scheme object is inserted as a fact into Drools' working memory. The engine automatically performs pattern matching and triggers the corresponding rules. The action part of the rule can generate a violation object and insert it into the result set. To improve check efficiency, incremental checks can be implemented for large configuration schemes, i.e., only the changed parts of the scheme are re-evaluated for the relevant rule subset.

[0046] The component composition analysis model service deployment and invocation in the second check is a key technical aspect. After model training, it needs to be packaged and deployed as a scalable microservice along with the feature engineering pipeline. Frameworks such as TensorFlow Serving or MLflow Models can be used for deployment. The service provides an API endpoint that receives raw data of the configuration scheme in JSON format. Internally, pre-loaded feature extraction code transforms the raw data into feature vectors required by the model; this process must be absolutely consistent with the training phase. Therefore, the feature transformers used during training need to be serialized and saved. The model inference part loads the serialized model file for computation. In scenarios such as finance and insurance where inference latency and throughput are critical, the model can be optimized, such as using TensorRT for acceleration or quantizing the model. For scenarios requiring interpretation of model prediction results, interpretability algorithms can be integrated into the service. For example, while invoking model inference, SHAP values ​​can be calculated to identify the few input features that have the greatest impact on the current prediction, and this information can be returned as part of the evaluation suggestions.

[0047] This embodiment automates the inspection of configuration schemes by utilizing explicitly defined business rules within the component association set. This efficiently and accurately identifies all issues violating preset logical constraints and compliance requirements, ensuring the correctness of the scheme at the deterministic rule level and avoiding oversights and inconsistencies that may occur during manual review. Simultaneously, by invoking a pre-trained component combination analysis model to intelligently evaluate the same scheme, it can predict the potential performance of the scheme in dynamic indicators such as risk and market performance based on historical data and complex pattern recognition, revealing deep-seated hidden dangers or optimization opportunities that rules alone cannot uncover. Finally, by systematically integrating the findings from rule checks and model evaluations, and structuring, prioritizing, and interpreting them, a comprehensive, clear, and actionable integrated inspection result is generated, providing decision-makers with multi-dimensional and in-depth quality insights, from hard compliance to soft prediction.

[0048] S70, when the inspection result indicates that publication is permitted, publish the configuration scheme.

[0049] In this embodiment, when the inspection result indicates that release is permitted, the release configuration scheme is a key execution process based on automated decision triggering, formally delivering or enabling the final approved solution product to the target environment. The inspection result is a structured output after the previous steps of double-verifying the configuration scheme, typically containing an overall status marker and a detailed list of compliance issues and assessment information. Determining whether the inspection result indicates permission to release requires the system to parse and evaluate the inspection result according to a set of explicit decision rules. These rules are typically defined as Boolean logic judgments on key fields in the inspection result. For example, a basic rule might be: release is permitted only if the "overall status" field of the inspection result is "passed". More complex rules may involve in-depth analysis of a specific list of issues; for example, the rule might require "no issues with a severity level of 'fatal' or 'error'" and "the weighted average confidence level of all model assessment warning items is below a preset risk threshold." The system needs to load these predefined release decision rules, use the currently generated inspection result as input, execute the rule engine or decision logic, and ultimately output a Boolean conclusion—release permitted or not permitted. This decision-making process automates the transition from quality assessment conclusions to issuing directives.

[0050] Deploying a configuration scheme refers to the process by which the system, upon receiving confirmation of permission to publish, performs a series of operations to transform and deploy this internal design artifact into a formal product usable by downstream systems, providing services externally, or entering production. Deployment is not a single storage action but a process comprising multiple sub-tasks. A core operation is updating the configuration scheme object's own state metadata, such as changing its status from "under design" or "pending review" to "published," and recording the release time, version number, and publisher information. Version control is crucial; each deployment should generate an immutable product version snapshot containing the complete scheme content, parameters, and all contextual information related to this deployment. The deployment process typically involves formatting the configuration scheme content to generate standardized product definition files that meet the requirements of the target system or interface. For example, in the financial insurance field, it may be necessary to convert the scheme into a rate table file readable by an actuarial system, a rule set loadable by an underwriting rule engine, and a product details page data package displayed by a front-end sales system. Simultaneously, the deployment operation triggers a notification mechanism, sending a successful deployment event message to relevant business systems or responsible personnel so that they can synchronize their status updates or retrieve the latest product data. Ultimately, the published configuration schemes are stored in the product release repository or master data management system, becoming part of the official product catalog and available for use in sales, underwriting, or service processes.

[0051] The decision logic for determining whether an inspection result can be published can be configured in various ways based on business risk tolerance and automation levels. One implementation is hard-coding rules, such as directly checking whether the `overallStatus` property of the inspection result object is "APPROVED" in the code. For scenarios requiring flexible rule adjustments, the decision rules can be configurable. For example, a rule configuration file can be used, where expressions define the conditions for allowing publication, such as `$result.overallSeverity != 'CRITICAL' && $result.riskScore < 0.7`. The system parses and executes these expressions at runtime. Another implementation is to integrate a lightweight decision engine, such as modeling the decision logic as a decision tree or decision table, with the engine reasoning based on the input results. The decision process can also introduce a manual approval step. For inspection results in a gray area, the system can generate a task to be done, delegating the final decision-making power to a designated person, and triggering automatic publication only after obtaining manual confirmation.

[0052] The implementation of the deployment configuration scheme can be adjusted according to the complexity of the target environment and integration requirements. For monolithic applications or simple scenarios, deployment can be a synchronous local operation, where the system updates the scheme status in the database within a transaction and generates static files stored in a specified directory. For microservice architectures or scenarios requiring multi-system collaboration, deployment should be designed as an asynchronous process with transaction compensation capabilities. Workflow engines or message queues can be used to orchestrate the deployment task sequence. For example, the deployment process can be broken down as follows: 1. Mark the scheme as "Deployment in Progress" in the scheme service; 2. Call the document generation service to create a product terms PDF; 3. Call the rate calculation service to generate the final rate and synchronize it to the pricing center; 4. Call the product master data service to register the new product entry; 5. After all steps are successful, update the scheme status to "Deployed" and send a domain event. Each step failure should be able to roll back or enter exception handling. Deployment channels can also be diversified. In addition to deployment to internal systems, it can also support direct deployment to partner platforms or regulatory agency filing systems, which requires the implementation of data adapters for specific protocols. Post-release version management can adopt a semantic version control strategy, automatically recommending version number upgrade rules based on changes to the solution.

[0053] Furthermore, after the configuration plan is released, the system enters a continuous optimization phase involving data collection and feedback learning. The core of this phase is collecting performance data of the product in a real market environment and using this newly generated data to optimize the two core knowledge assets supporting the product configuration—component association sets and component combination analysis models—thus forming a self-evolving learning loop. Collecting product performance data is the foundation of the optimization process. This data, generated after the product's release during actual sales, service, and operation, reflects its market acceptance, risk level, customer satisfaction, and operational efficiency—both quantitative and non-quantitative information. In the medical finance and insurance field, performance data can be very broad, such as the claim occurrence time, disease diagnosis, total treatment cost, actual payout amount, and payout cycle for each effective policy; monthly or quarterly new policy sales volume, channel distribution, and customer age and gender distribution; customer renewal rate, surrender rate, and related customer service inquiries and complaints; as well as more macro-level changes in the product's market share and competitor comparisons. The data collection process requires establishing automated data connections with core business systems, claims systems, customer relationship management systems, and external market data platforms. Relevant data is periodically extracted, cleaned, and aggregated according to a preset time granularity. This newly collected data is associated with product configuration schemes through a unique scheme version identifier, ensuring that performance data can be accurately traced back to its original design source.

[0054] Updating the component association set based on collected product performance data is a process of validating, revising, and enriching the business logic relationships between components using the latest best practices. The dependencies, mutual exclusions, and other relationships defined in the component association set are not static; new market feedback may reveal previously undiscovered association patterns or prove that certain historical associations are no longer applicable in the current environment. The update process first requires association analysis of the new performance data. For example, analyzing the actual co-occurrence patterns of different standard components in the new data under new customer groups or market conditions, and calculating new support and confidence indices. By comparing the newly calculated indices with the existing rule-based indices in the association set, it is possible to identify associations that need to be strengthened, weakened, or added. One scenario is the discovery of new strong dependencies: if data shows that when component A and component B are almost always selected simultaneously in a new sales scenario, and the customer satisfaction after pairing them is significantly higher, then it may be necessary to add a "recommendation dependency" relationship from A to B to the association set. Another scenario involves resolving existing conflicts: if historical rules deem components C and D mutually exclusive, but new market data indicates that they can coexist without posing anticipated risks in specific product forms (such as high-end product lines), then the strength of the mutual exclusion rule can be adjusted or additional conditions can be added to its application. Updates may involve adjusting existing rule parameters or adding / deleting rule entries. This process transforms the component association set into a living knowledge base that evolves dynamically with business practices.

[0055] Updating component combination analysis models based on product performance data involves retraining or incrementally learning deployed prediction or evaluation models using newly generated, labeled real business data to improve their predictive accuracy and timeliness. Model performance can drift with changes in market environment and customer behavior; regular updates are crucial for maintaining its effectiveness. The update process first requires constructing new training samples using newly collected performance data. The sample construction method remains consistent with the initial model training: input features are the component combination features and contextual features of the corresponding published configuration scheme, while labels are the business results observed during the actual operation cycle of the scheme, such as actual claims rates and sales target achievement rates. These new samples are merged with historical training data to form an expanded training dataset. Model updates can employ various strategies. One is full retraining, which uses all historical data plus new data to retrain a new model. This method can obtain the globally optimal solution but has high computational costs. Another more efficient method is incremental learning, where the model retains existing knowledge while fine-tuning parameters using only new data, quickly adapting to recent data patterns. Within a deep learning framework, this can be achieved by running a few training epochs on new data with a low learning rate, building upon the existing model weights. Key training parameters, such as the learning rate and batch size, need to be specifically tuned for incremental learning scenarios to prevent catastrophic forgetting. After the model is updated, rigorous offline evaluation is required. Using a retained validation set or time-slice test set, its performance improvement on new data must be assessed to ensure that the updated model is superior to or at least no worse than the old model before it can be deployed online to replace the old model. This enables the component-based analytics model to continuously learn from the latest business results.

[0056] This embodiment automates the parsing of inspection results and determines whether release conditions are met through clearly defined rules, achieving a seamless connection from quality assessment to release decision-making. It eliminates the subjectivity and delays of manual judgment, ensuring that only solutions meeting preset quality standards can enter the release process. Once the release instruction is received, the system automatically executes a series of standardized release operations, including updating the solution status, performing version control, converting data formats, notifying relevant parties, and archiving release artifacts. This efficiently, accurately, and consistently transforms the validated configuration solution into a usable formal product. This mechanism also incorporates the final stage of product release into automated management, ensuring a closed-loop and controllable chain from design and inspection to release, greatly improving the speed, reliability, and compliance of product deployment.

[0057] In one embodiment, step S10 includes: S101, acquire historical product data, perform document layout recognition and noise removal on the historical product data, generate cleaned historical product data, and parse the cleaned historical product data to determine the text paragraph hierarchy structure. S102, based on the text paragraph hierarchy, perform key entity identification on the cleaned historical product data, and extract product element information including functional description, execution conditions, exclusion restrictions and numerical factors; S103, map the product element information to a preset standard data model, assign attribute labels and identifiers to the mapped product element information, and combine the attribute labels, the identifiers and the mapped product element information into a standard component with independent semantics. S104, determine the functional category of the standard component based on the identifier and the attribute label; S105, store standard components whose function category is basic information into the basic information field of the component library, store standard components whose function category is core function into the core function field of the component library, store standard components whose function category is value-added service into the value-added service field of the component library, and store standard components whose function category is adjustment factor into the adjustment factor field of the component library.

[0058] In this embodiment, acquiring historical product data involves extracting complete definition information of past products stored in unstructured or semi-structured document format from heterogeneous data source systems within the enterprise. These data sources include product management systems, contract archives, actuarial model file servers, and filing material repositories submitted to regulatory agencies. Specific data entities include PDF-format insurance policy documents, Word-format product development requirement documents, Excel-format rate calculation sheets, and HTML-format online product display pages. Data acquisition is accomplished by calling system APIs, accessing shared file directories, or querying database views, aggregating scattered raw documents into a unified temporary storage area to provide unprocessed raw materials for subsequent processing.

[0059] Document layout recognition and noise removal are performed on historical product data to strip away the physical format and irrelevant presentation information of the original documents, restoring their logical text content and visual structure. Layout recognition utilizes computer vision and document image analysis techniques to process document images or mixed-format files obtained through scanning or direct acquisition. This process uses a pre-trained document layout analysis model, typically based on an architecture such as LayoutLMv3. This model simultaneously receives document image blocks and corresponding text sequences extracted from an OCR engine as input. Its visual encoder processes image features, and its text encoder processes word embeddings, then fuses the two features through a cross-modal encoder. The model's output is fine-grained classification labels and bounding boxes for each text region, identifying logical blocks such as headings, paragraphs, list items, tables, headers, footers, and watermarks. Based on the identified layout, the system performs noise cleaning, which includes removing text areas identified as headers, footers, page numbers, and irrelevant watermarks; removing special characters purely for typesetting, redundant spaces, and line breaks; and correcting character recognition errors in the OCR results caused by image blurring using a context-based language model-based error correction algorithm. After this processing, the resulting historical product data is cleaned, removing formatting interference and retaining the main text content and initial logical block divisions.

[0060] Analyzing the cleaned historical product data to determine the hierarchical structure of text paragraphs builds upon layout recognition to further understand the internal organizational logic of the document content, constructing a tree structure reflecting the hierarchical relationships between chapters, sub-chaps, and paragraphs. The parsing process analyzes text blocks already marked as titles and paragraphs. The system infers the hierarchical level based on the visual characteristics of the titles, text prefixes, font size, and their spatial position on the page. The algorithm analyzes the title sequence, applying predefined rules or training a sequence labeling model to determine the nesting relationships between titles. For documents without explicit title markings, the implicit hierarchy is inferred based on information such as paragraph indentation, bullet points, and numbering sequences. The final output is a structured document object model that precisely records the hierarchical path of each text segment, such as "Chapter 1 > Section 1 > Paragraph 1". This hierarchical structure provides a precise navigation map for subsequent location and extraction of product elements within a specific context.

[0061] Key entity identification based on the hierarchical structure of text paragraphs in cleaned historical product data involves automatically locating, classifying, and extracting information fragments that constitute the smallest functional units of a product from structured text. Key entities here specifically refer to four categories of elements: functional description, execution conditions, exclusion restrictions, and numerical factors. This relies on a natural language processing sequence labeling model fine-tuned for the financial insurance domain. The model is built using a pre-trained language model as the encoder, employing either BERT or RoBERTa architecture. The model input consists of text sentences that have undergone word segmentation and sub-word splitting, concatenated with the feature encoding of the paragraph-level path within that sentence. The model captures contextual semantics through a multi-layered Transformer encoder and incorporates a Conditional Random Field decoding layer at the top to jointly infer the optimal entity label sequence. Training this model requires a large-scale labeled corpus of insurance clauses, where each term is labeled with tags such as B-Function (start of functional description), I-Function (within functional description), B-Condition (start of execution conditions), B-Exclusion (start of exclusion restrictions), and B-Value (start of numerical factors). Training parameters include learning rate, batch size, number of encoder layers, and CRF transition matrix constraints. In the medical finance and insurance scenario, the model identifies the functional description "payment of malignant tumor insurance benefits," the execution conditions "occurring after the waiting period" and "compliant with the terms of this contract" and the numerical factor "100%" from sentences such as "Our company will pay 100% of the basic insurance amount as malignant tumor insurance benefits for malignant tumors that occur after the waiting period and conform to the terms of this contract." The identified entities, along with their position and hierarchical level in the original text, are recorded.

[0062] Mapping product element information to a pre-defined standard data model is a process of transforming non-standardized natural language descriptions into standardized data objects with a unified schema definition. The pre-defined standard data model defines the set of fields, data types, and constraints that each standard component must contain. The mapping process is a rule-based transformation engine. The engine reads the structured element information obtained from the entity identification step and matches the corresponding mapping rules according to the element type. For example, a text fragment identified as a functional description is mapped to the "functional description" field of the standard data model; a text fragment identified as an execution condition is analyzed and converted into a structured logical expression, which is then filled into the "applicable conditions" field; numerical factors are parsed and associated with specific parameter names, filling the "parameter list." During this process, the system assigns a globally unique identifier and one or more attribute labels to each data object generated after mapping. The identifier is generated according to a defined algorithm to ensure its uniqueness and traceability. Attribute labels are then labeled according to the entity's content and context, such as assigning business labels like "long-term care" or "high-frequency claims" to a responsible entity.

[0063] Combining attribute tags, identifiers, and mapped product element information into standard components with independent semantics encapsulates the aforementioned mapping results, creating a well-defined, self-contained data unit that can be independently referenced and processed. The combination operation instantiates scattered fields (identifiers, attribute tags, functional descriptions, applicable conditions, parameters, etc.) into a specific component object according to the definition of a standard data model. This object, in memory or after serialization, represents a structured data record, such as a JSON object or a row in a database table. Its "independent semantics" are reflected in the fact that the object contains all the necessary information to define its own function, and can be understood and used without relying on the context of external documents. For example, a standard component named "COMP_DIABETES_OUTPATIENT" encapsulates all the definitions, rules, and parameters related to diabetes outpatient insurance benefits.

[0064] Determining the functional category of standard components based on identifiers and attribute tags involves categorizing the constructed standard components according to predefined classification logic. The encoding rules of identifiers may implicitly contain category information, such as starting with a specific prefix. Attribute tags provide a more direct basis for classification. The system maintains a mapping table or decision rules from specific attribute tag combinations to functional categories. For example, a component with tags such as "basic rate" or "policyholder information" is classified as "basic information." If it has tags such as "core coverage" or "main insurance liability," it is classified as "core function." This determination process can be accomplished through simple rule matching or a lightweight classifier.

[0065] Storing standard components of different functional categories into corresponding storage domains of the component library involves physically or logically partitioning the storage based on the business nature of the components to achieve efficient organization and management. The component library is typically implemented physically by a database, with its logical structure pre-divided into different domains. The basic information domain stores components used to define product metadata and framework; the core functionality domain stores responsibility or service components that constitute the product's main value proposition; the value-added service domain stores additional benefits components that enhance product appeal; and the adjustment factor domain stores parameterized components that affect pricing, duration, or effective conditions. The storage operation involves persisting all data of the standard component objects, based on their defined functional categories, to the corresponding database tables or collections. Simultaneously, multi-dimensional indexes are established for component identifiers, attribute tags, and functional categories to support subsequent rapid retrieval, filtering, and combination calculations. This completes the entire process of transformation and accumulation from raw documents to standardized, categorized, and reusable digital assets.

[0066] This embodiment achieves accurate extraction of structured text content by automating layout recognition, noise removal, and hierarchical parsing of historical product documents, overcoming the bottleneck of unstructured data processing. Based on this, a key entity recognition model customized for the application domain can systematically extract core product elements such as functions, conditions, limitations, and values ​​from the text, achieving automated and high-precision information extraction. These elements are further mapped to a unified data model and encapsulated as standard components, giving the original information clear semantic boundaries and a machine-processable standardized format. Automated classification and partitioned storage based on component attributes construct a well-structured, easily searchable, and manageable standardized component library. This process systematically transforms scattered, non-standard historical product knowledge into high-quality, reusable digital component assets, laying a solid data foundation for highly modular and automated product configuration.

[0067] In one embodiment, step S20 above includes: S201, Obtain historical business data, and extract product configuration samples containing standard components from the component library from the historical business data; S202, Analyze the co-occurrence frequency of different standard components in the product configuration sample to determine the dependency and conflict relationships between the standard components; S203, store the dependency relationship and the conflict relationship as a structured mapping file to generate a component association set; S204, Obtain the operating indicator data corresponding to the product configuration sample from the historical business data, and associate the standard component combination in the product configuration sample with the corresponding operating indicator data to construct a training dataset; S205, with the goal of analyzing the operating indicators corresponding to the standard component combination, machine learning is performed using the training dataset to generate a component combination analysis model.

[0068] In this embodiment, historical business data is acquired by aggregating process records from the enterprise's core operating systems, reflecting the actual use, sales, and results of products in the market. These systems include policy management databases, claims processing systems, financial settlement platforms, and customer relationship management software. The data format is primarily highly structured transaction record tables, such as database tables containing fields like policy number, policy date, product code, insured attributes, premium, claims application number, payout amount, and payout status. The acquisition operation is completed by executing an ETL job in the data warehouse or directly querying a read-only copy of the production system, ensuring that the acquired data is a snapshot of historical data that has been anonymized and verified for business integrity.

[0069] Extracting product configuration samples containing standard components from the component library from historical business data is a process of associating and mapping raw business records with knowledge-based component assets. First, the system parses the product identification information in each historical business record. Then, by querying the component library, it finds all the standard components that constitute the product during that historical period. This mapping relies on the relationship between product versions and component versions. For example, a historical policy record might have a product code of "HLI_2023_Q1." The system queries the product-component relationship graph to retrieve all enabled standard component identifiers under that product version, such as "COMP_INPATIENT" and "COMP_CANCER." Simultaneously, relevant contextual information from the business record is extracted, such as the policyholder's age range, sales channel, and policy effective date. Finally, each valid historical business record is transformed into a sample unit. The core of this unit is an ordered or unordered set of standard component identifiers, accompanied by relevant business context metadata.

[0070] Analyzing the co-occurrence frequency of different standard components in product configuration samples to determine the dependencies and conflicts between them is a process of mining stable association patterns between components from a large number of real-world samples using statistical methods. The system first traverses all product configuration samples, constructing a co-occurrence matrix for the component set in each sample. For any two standard components, it calculates the number of times they appear simultaneously in all samples and the number of times they appear individually. Dependencies are determined based on indicators such as conditional probability and lift. For example, the probability of component B appearing given component A is calculated. If this probability is significantly higher than the global probability of component B, and the statistical test is significant, then A is determined to be dependent on or strongly associated with B. Conflict relationships are determined by analyzing negative correlation patterns and mutual exclusivity. If the frequency of two components appearing simultaneously in the samples is extremely low, below the expected value of random co-occurrence, and can be interpreted as mutually exclusive from a business logic perspective, then a conflict relationship is determined. The analysis process can be automatically executed using association rule mining algorithms such as Apriori and FP-Growth. Minimum support and minimum confidence thresholds can be set to filter noise, and the output will be a set of rules in the form of "{COMP_A, COMP_B} → Dependency (Confidence = 0.92)" or "{COMP_C, COMP_D} → Conflict (Support = 0.01)".

[0071] Storing dependencies and conflicts as structured mapping files to generate component association sets is a process of persisting and standardizing the mined rule knowledge. Each relationship is defined as a specific type of "edge," with its "source node" and "target node" being unique identifiers for standard components. Edge attributes include relationship type (dependency / conflict), strength metrics (such as confidence and lift), and possible effective conditions (such as applicable only to a certain type of customer). Structured mapping files can be stored using edge list format in graph databases, rule arrays in JSON format, or table structures in relational databases. Generating association sets involves writing all analyzed relationship rules into this file or database and creating an index based on component identifiers to support efficient operations such as "querying all components that have dependencies on component X."

[0072] Retrieving operational indicator data corresponding to product configuration samples from historical business data involves precisely aligning process-oriented business records with outcome-oriented performance indicators. Operational indicator data consists of quantitative values ​​observed in subsequent operating cycles for each product configuration sample. For a historical policy sample, its operational indicators might include the total claims amount during the observation period, a Boolean flag indicating whether a claim occurred, the number of months the policy lasted, and the final renewal / surrender status. This data needs to be aggregated and calculated from financial statements, claims details, and policy status change logs using association keys. The acquisition process must ensure consistency within the time window, such as calculating the cumulative claims amount within 12 months of a policy's inception.

[0073] Associating standard component combinations from product configuration samples with corresponding operational indicator data to construct a training dataset is a crucial step in creating a labeled sample set for supervised machine learning. The association operation connects the component combinations extracted in the previous step with the calculated operational indicators based on the business primary key. Each training sample consists of a feature part and a label part. The feature part is a numerical representation of the component combination, typically using multi-hot encoding to generate a sparse binary vector of length equal to the total number of components in the component library. Each dimension corresponds to a specific component; the value is 1 if the combination contains that component, and 0 otherwise. The feature part can also incorporate contextual information such as the normalized value of customer age and the category code of the sales channel. The label part is the operational indicator value to be predicted, which can be a continuous value or a discrete classification label. All successfully associated samples are divided into training, validation, and test sets, completing the dataset construction.

[0074] This study aims to analyze operational metrics corresponding to standard component combinations. Using a training dataset, machine learning is employed to generate a component combination analysis model. This process involves training a predictive model capable of learning a complex mapping function between component combination features and business outcomes. The model employs a deep neural network architecture. The input layer receives the aforementioned multi-hot encoded feature vectors and context feature vectors. Due to the high dimensionality and sparseness of component features, the model first uses an embedding layer to map the binary identifier of each component into a low-dimensional, dense real-valued vector space. The embedding vectors of multiple components are then aggregated and concatenated with the context feature vectors. The concatenated vector is input into a multi-layer fully connected network, with each layer containing a sequence of operations including linear transformation, batch normalization, ReLU activation, and Dropout regularization. Network depth and width are hyperparameters. The output layer is designed according to the prediction task: if predicting continuous operational metrics (such as claims costs), a linear neuron is used; if predicting categorical labels (such as high / low risk), a Softmax function is used to output the probability distribution. The model training process uses supervised learning. The loss function is chosen based on the task, selecting either mean squared error or cross-entropy. The optimizer used was Adam, with an initial learning rate of 0.001 and a learning rate decay strategy based on validation set performance. Training was performed in batches with a batch size of 256, iterating multiple times on the training set, and evaluating performance on the validation set after each batch. Early stopping was used to prevent overfitting. Finally, the model that achieved satisfactory performance on the test set was serialized and saved, becoming a component portfolio analysis model that can be used to analyze operational metrics for new component combinations.

[0075] This embodiment extracts product configuration samples composed of standard components from historical business records, linking actual business with component-based knowledge. By analyzing the statistical co-occurrence patterns of components in the samples, it automatically and data-drivenly mines the dependencies and conflicts between components, constructing a structured set of associations to make implicit business constraints explicit and rule-based. Furthermore, by precisely aligning historical component combinations with actual operational results data, a high-quality supervised learning dataset is constructed, and a deep neural network model is trained using this dataset. This enables the model to internalize the complex nonlinear mapping from product composition to market or risk performance. This process achieves the dual purpose of simultaneously and automatically extracting deterministic business rules from historical business data and training predictive intelligent models, providing a two-layer intelligent support for product configuration: rule-based hard constraints and model-based soft evaluation.

[0076] In one embodiment, step S30 above includes: S301, extract standard components from the basic information domain, core function domain, value-added service domain and adjustment factor domain of the component library; S302, in the visual interface, the extracted standard components are graphically rendered through a tree structure or matrix view; S303, capture click operations on the graphically rendered standard components through the visual interface, and obtain component selection instructions containing the standard component's identity identifier; S304, extract the standard component identity identifier from the component selection instruction, and obtain the attribute data of the selected standard component corresponding to the identity identifier from the component library; S305, the selected standard component is structurally encapsulated according to the attribute data to form a component selection combination.

[0077] In this embodiment, extracting standard components from the basic information domain, core function domain, value-added service domain, and adjustment factor domain of the component library involves initiating a series of parallel data query operations to the storage system based on a preset business classification logic. Each storage domain may physically correspond to an independent data table, set, or data partition with specific tags. The extraction process sends a request to the component library's query interface, which includes the classification identifier of the target domain as a filtering condition. The query interface parses the request and generates internal query statements for different storage domains, such as performing a SELECT operation with the WHERE domain='CORE_FUNCTION' condition on a relational database, or performing a FIND operation filtered by the category field on a document database. To improve response speed, the system can cache results for frequently accessed domains and preload a list of commonly used components into memory. The extraction operation returns a set of standard component objects that conform to the business classification. Each object contains its predefined identifier, name, type, and other metadata, which constitute the raw dataset for subsequent visualization rendering.

[0078] In a visual interface, rendering extracted standard components graphically using a tree structure or matrix view is a process of converting abstract data objects into visual encodings of screen pixels. Tree structure rendering constructs a node hierarchy based on the component's own hierarchical attributes or the classification relationship of its domain. The rendering engine first organizes the flattened list of components into a tree data model, with the root node being the component library, first-level child nodes being the various domains, and leaf nodes being the specific components. The front-end framework's tree control receives this data model, recursively creates corresponding DOM elements for each node, and uses CSS to control visual styles such as indentation and connectors to display the hierarchy. Matrix view rendering ignores the hierarchy, treating components as equal entities for grid-based layout. The system calculates the size of the interface container, dynamically calculates the number of cards that can be accommodated in each row based on the size of the component's visual card, and uses a CSSGrid or Flexbox layout engine to arrange the component cards into a regular matrix. Each component card is an independent UI component instance, and its template defines the card's visual structure: an icon placeholder, a component name label, a brief description text, and a type badge. During rendering, the card UI component receives data from the corresponding standard component object, performs data binding, and fills the corresponding positions of the template with attributes such as name and description, ultimately generating a graphical element that the user can directly perceive.

[0079] By capturing click actions on graphically rendered standard components through a visual interface and obtaining component selection instructions containing the standard component's identity, a mapping link is established in the browser's or application's event system from the user's physical actions to logical instructions. When a user clicks on a rendered component card, the browser generates a mouse click event object. This event object is propagated through the DOM event bubbling mechanism. To capture this action, the system binds an event listener to the root DOM element of each component card. When the listener function is triggered, its execution logic first blocks the event's default behavior, then parses the business data associated with the clicked element—that is, the unique identifier assigned to the component card at creation—from the event object's target property or its specific data properties. Subsequently, the listener function constructs a structured instruction object. This object is a lightweight data carrier whose fields include at least the instruction type (such as "SELECT"), a timestamp, and, most importantly, the target component's identity identifier. This instruction object is placed in an instruction dispatch queue or directly dispatched globally through a state management framework, thus completing the crucial transformation from user interface interaction to internal logical events.

[0080] Extracting the standard component identity identifier from the component selection instruction and retrieving the attribute data of the selected standard component corresponding to the identity identifier from the component library is an operation that retrieves the complete component definition from persistent storage based on the user's selection intent. The instruction processing module extracts the identity identifier field from the dispatched instruction object. This identifier is a unique key for locating component data. The system uses this identifier as a query parameter to call the component library's data service interface. After receiving the identifier, this interface performs a precise query in the underlying database, for example, using SELECT. The SQL statement `FROM component_table WHERE uuid = ?` returns a complete dataset of the component's attributes at the time of its import into the database. This includes core business attributes such as its functional description, parameter list, constraints, and applicable rules. These attributes may not all be loaded during the initial rendering. To ensure data consistency, this query is typically performed on the server-side, returning the complete component attribute data to the front-end in formats such as JSON. Upon receiving the data, the front-end application temporarily stores it in a temporary "selected component pool" data structure. This pool uses the component identifier as the key and the complete component attribute object as the value, providing complete resources for subsequent encapsulation operations.

[0081] The selected standard components are structurally encapsulated according to the attribute data to form a component selection composition. This involves aggregating and organizing multiple independent component instances and their complete attributes into a well-defined composite data object representing the current configuration intent. The encapsulation process is executed by a composition manager module. This manager maintains the state of the current session, which contains a list recording the identifiers and complete attribute data snapshots of all selected components. The composition manager is triggered when new component attribute data is retrieved and added to the "selected component pool." It reads the attribute data of all active components from the pool and assembles them according to a predefined composition data model. This data model defines the structure of the component selection composition object, typically containing the following fields: a unique session ID for the composition, a composition generation timestamp, and a core `components` array. Each element in the array corresponds to a selected component, and the element itself is a nested object containing all attribute data of that component retrieved from the component library, and possibly instantiation parameters appended to the current composition. In addition, the composition object may also contain metadata dynamically calculated based on the currently selected component list, such as component type statistics and estimated baseline metrics. After encapsulation, the generated structured component selection composition object is stored in memory or client persistent storage and serves as the authoritative state representation of the current configuration session, which can be directly consumed by subsequent recommendation, solution generation and other processes.

[0082] This embodiment provides users with clear and structured visual navigation by extracting and categorizing components according to business domains, significantly reducing the cognitive burden and time cost of locating targets from a massive number of components. Utilizing tree or matrix views for graphical rendering transforms data into intuitive, interactive objects, establishing a user-friendly interface. Accurately capturing click events and generating identifiable instructions achieves lossless, real-time conversion of user intent into machine-processable commands. Retrieving complete attribute data from the library based on instruction identifiers ensures the integrity and accuracy of component information used in subsequent processing. Finally, the complete attributes of multiple components are encapsulated into a unified structured composite object, creating a clearly defined, comprehensive configuration task input that can be directly used for downstream intelligent processing. This process achieves a complete closed loop from browsing and selection to the formation of structured input, transforming complex product configuration into efficient graphical interactive operations.

[0083] In one embodiment, step S40 above includes: S401, parse the component selection combination and determine the standard components already included in the component selection combination; S402, compare the included standard components with the component association set to determine necessary supplementary components that have a dependency relationship with the included standard components and are outside the component selection combination; S403, Based on the component association set and the component selection combination, determine candidate completion components from the component library as feature completion items; S404, input the selected component combination, the necessary supplementary components, and the feature completion items into the component combination analysis model; S405, The component combination analysis model is used to perform multi-dimensional analysis on the component selection and combination, the necessary supplementary components and the feature completion items to determine the degree of correlation of each feature completion item; S406, integrate the necessary supplementary components and feature completion items whose relevance meets the preset screening conditions to generate component recommendation information.

[0084] In this embodiment, parsing the component selection combination to determine the standard components it contains is a process of extracting the precise set of elements representing the current configuration intent. The component selection combination is a structured data object, typically containing a `components` array field. Each element in the array represents a selected component and includes at least its globally unique identifier. The parsing operation reads the entire list of component identifiers by accessing specified attributes of this data object. To ensure data consistency and validity, the system may simultaneously perform a validation query, sending each identifier in the list to the component library for rapid existence verification, filtering out any invalid or logically deleted identifiers, and finally outputting a cleaned set consisting of the actual standard component identifiers present in the current combination. This set serves as the deterministic input basis for all subsequent analysis operations.

[0085] The process of comparing the existing set of standard components with the set of component associations to determine necessary supplementary components is a rule-based logical completeness check and completion derivation process. The system first loads the set of component associations, which stores the dependencies between components in the form of a graph structure or a list of rules. For each component in the current component set, the system queries the association set for all dependency rules that require that component as a prerequisite. Each such rule takes the form "If component A exists, then component B must exist." The system then checks whether the conclusion of the rule, component B, already exists in the current component set. If it does not exist, component B is marked as a potential missing dependency. This process iterates through all components and all their dependency rules, resulting in a candidate list of missing dependency components. The system may further apply business logic for filtering, for example, only accepting missing components resulting from rules marked as "strong dependency" or "mandatory," while ignoring "recommended" dependencies. The final list of necessary supplementary components represents the set of components that must be added to the current combination to satisfy existing business rule constraints, and is a mandatory requirement to ensure the logical correctness of the solution.

[0086] Based on component association sets and component selection combinations, the process of identifying candidate components from the component library as feature completion items is a data-driven screening process designed to expand combination possibilities and introduce intelligent optimization options. This process does not search for missing items, but rather explores potential value-added or optimization items. Its screening logic integrates multiple signals. One signal is based on non-mandatory associations in the association set, such as historical co-occurrence patterns. The system calculates the association strength metric between components in the current component set and other unselected components in the component library, selecting those unselected components whose association strength exceeds a certain threshold as candidates. Another signal is based on heuristic rules of diversity or coverage, such as selecting typical or popular components from functional categories not yet covered by the current combination. The screening process typically generates a controllable list of candidate components, such as the Top-K. These candidate components are called "feature completion items," representing optional components that, based on data patterns, are worth considering adding to the existing combination and may improve the overall value of the combination.

[0087] The component selection combination, necessary complementary components, and feature completions are input into the component combination analysis model. This requires integrating these three types of information and transforming them into a numerical feature representation that the model can process. Feature engineering constructs a unified feature vector. For the component selection combination, a base vector V_base is generated using multi-hot encoding. For the list of necessary complementary components, a similar vector V_necessary is generated, but it is usually distinguished from the base combination by a flag or lower initial weight. For each feature completion, the system does not encode it all at once, but rather constructs an independent input instance for each completion to be evaluated by the model. Therefore, for each feature completion C_i to be evaluated, the system constructs a feature vector V_i. V_i is composed of the following parts: the first part is V_base, representing the original combination; the second part is a special encoded vector used to identify the currently evaluated completion C_i; and the third part is the contextual features of the current combination and completion C_i, such as a scalar value of the association strength between the two, which may be extracted from the association set. This method of constructing an input vector separately for each candidate allows the model to evaluate the incremental value of each candidate in a consistent context.

[0088] The component combinatorial analysis model performs multi-dimensional analysis of the input to determine the correlation between each feature completion item. This process involves the model performing forward inference and generating a quantitative evaluation. The component combinatorial analysis model is a trained deep neural network whose final layer outputs a scalar score. When the feature vector V_i is input into the model, the data flows through each layer of the network. After receiving the vector, the input layer first passes it through an embedding layer, which maps the high-dimensional sparse component identifiers to low-dimensional dense embedding vectors. These embedding vectors are then concatenated with other numerical features after passing through an aggregation function. The concatenated vector is then input into multiple fully connected layers, each containing linear transformations, batch normalization, ReLU activation, and Dropout operations. Through these non-linear transformations, the network learns a complex mapping from the input features to the final evaluation target. The output layer uses a sigmoid or linear activation function to produce a score S_i between 0 and 1 or a certain interval. This score S_i represents the "degree of correlation" between the feature completion item C_i determined by the model and the current component selection combination under a given business objective. It quantifies the extent to which adding C_i may bring about an expected increase in benefits or a reduction in risk. The model calculates its score independently for each feature completion item in the input list.

[0089] Integrating necessary supplementary components with feature completions that meet preset filtering criteria to generate component recommendation information is a decision-making and information synthesis process. Preset filtering criteria apply to the correlation score output by the model; for example, setting an absolute threshold (e.g., S_i > 0.6) or employing a relative ranking strategy (e.g., selecting the top 3 items with the highest scores). The system filters out feature completions that meet the criteria. The integration operation merges two types of components: one is a mandatory list of necessary supplementary components, which are unconditionally included in the final recommendation; the other is a list of filtered feature completions. For each merged recommendation component, the system constructs a detailed recommendation entry. This entry includes the component identifier, recommendation type, source basis, and the correlation score calculated by the model. Finally, all these entries are organized into a structured recommendation information object, which can be returned to the front-end interface as an API response or published as an event message to downstream solution processing flows, thus completing the transformation from intelligent analysis to specific, actionable recommendations.

[0090] This embodiment automatically identifies the components necessary to meet business logic completeness requirements by parsing the current combination and comparing it with the associated set according to rules, ensuring basic compliance of the configuration scheme. Furthermore, it intelligently filters candidate completion items from the component library based on data patterns, providing a range of options for optimization. Utilizing a component combination analysis model, it independently and quantitatively evaluates the correlation degree of each candidate item, achieving accurate value ranking based on historical data and complex pattern recognition. Finally, it combines mandatory completion items with intelligently recommended items that pass the filtering process to generate structured recommendation information. This process organically combines rule-based deterministic completion with model-based probabilistic recommendation, providing automated suggestion generation capabilities for product configuration that combine compliance assurance and intelligent optimization.

[0091] In one embodiment, step S50 above includes: S501, parse the component recommendation information and obtain the recommended components contained in the component recommendation information; S502, merge the recommended components with the component selection combination to construct a temporary candidate component set; S503, the temporary candidate component set is verified according to the mutual exclusion constraints and dependency conditions defined in the component association set, and conflicting components and missing dependent components in the temporary candidate component set are identified. S504, Based on a preset conflict resolution strategy, process the conflicting components and supplement the missing dependent components to determine the final valid component set; S505, obtain a preset product structure template, map the standard components in the final effective component set to the corresponding nodes of the product structure template, and generate a configuration scheme with a hierarchical structure.

[0092] In this embodiment, parsing component recommendation information to obtain the recommended components it contains is a process of deserializing a structured recommendation data into a list of standard component objects that can be directly manipulated by the program. Component recommendation information is typically a data packet that explicitly labels metadata such as recommendation type, target component identifier, recommendation basis, and confidence level. The parsing operation first identifies the structure and format of the data packet, then locates and extracts the fields used to identify the recommended components, such as an array named "recommendedComponentIds". Subsequently, based on each extracted component identifier, the system initiates a single or batch query to the component library to obtain the complete definition data of these components. This process ensures that the "recommended components" processed in subsequent operations are living data entities carrying complete attributes and completely consistent with the definitions in the component library, rather than just identifiers.

[0093] Merging recommended components with component selection combinations to construct a temporary candidate component set is a set operation aimed at aggregating all intended components and forming the basic raw materials for solution processing. The merging operation needs to handle two sets that may contain overlapping elements: the set of user-selected components from the component selection combinations, and the set of recommended components parsed from the recommendation information. The merging algorithm typically performs a union operation on the sets, while handling possible overlaps according to a strategy. One strategy is to retain only one instance when a recommended component overlaps with a user-selected component; another strategy might be to assign higher weights or special labels to the overlapping components. The resulting temporary candidate component set is typically a list or set containing unique identifiers and complete attribute data for all components. This set is a transitional working copy that may contain internal contradictions, providing a clear operational object for subsequent deep validation and correction.

[0094] Validating the temporary candidate component set based on the mutual exclusion constraints and dependency conditions defined in the component association set is the process of logically auditing the set using application business rules. The validation engine loads two sets of rules simultaneously. For mutual exclusion constraints, the engine iterates through all component pairs in the temporary candidate component set, querying the association set for rules defining mutual exclusion. If a rule exists, the component pair is marked as a conflict instance. For dependencies, for each component in the set, the engine queries the association set for all rules that depend on that component, i.e., "If component A exists, then component B must exist." It then checks if the target component B in the rule exists in the current set. If not, it records that component A is missing its dependent component B. The validation process needs to efficiently handle potential combinatorial explosion problems, typically achieved by creating an inverted index for the association set and using incremental validation or batch processing optimization algorithms. The output consists of two clear diagnostic reports: one is a list of conflicting components, specifying the specific mutual exclusion rule violated for each conflict pair; the other is a list of missing dependent components, indicating which component lacks which necessary dependency.

[0095] The process of resolving conflicting components and supplementing missing dependencies based on a pre-defined conflict resolution strategy to determine the final effective component set is a process of repairing a problematic intermediate set into a logically complete final set based on business logic decisions. The conflict resolution strategy is a configurable decision logic module. A typical strategy is a priority strategy, such as specifying that the component originally selected by the user has a higher priority than the recommended component. When a conflict pair is detected, the system compares the source priorities of the conflicting components and automatically removes the one with the lower priority. Another strategy may involve calling an auxiliary evaluation model to calculate a value score for each conflicting component in the current context, retaining the one with the higher score. The process resolves all identified conflicts one by one, removing components eliminated by the decision from the set. For missing dependencies, the processing is deterministic: the system directly adds all identified missing dependencies to the set according to dependency rules. After conflict resolution and dependency completion, the resulting set is called the final effective component set. This set satisfies all mutual exclusion constraints, and all mandatory dependencies of all components are within the set, making it a logically self-consistent component package that can independently constitute product functionality.

[0096] The process of obtaining a pre-defined product structure template and mapping standard components from the final set of valid components to their corresponding nodes in the template to generate a hierarchical configuration scheme is the instantiation of a functional component set into a specific product form. The product structure template is a blueprint-like data structure that defines the overall product framework, module division, hierarchical relationships, and attribute slots for each module. The template can be represented as JSON Schema, XML Schema, or a domain-specific template language. The mapping process is a rule-based pattern matching and population operation. The system iterates through each component in the final set of valid components, searching for a predefined, matching target node in the product structure template based on the component's type attribute. For example, a component of type "Core Responsibility" is mapped to the "Responsibility List" node under the "Insurance Responsibility" section in the template. Mapping includes not only placing component references but also filling in the detailed parameters of the component into the corresponding attribute fields defined under that node. For cases with multiple components of the same type, the mapping logic also needs to handle list generation and sorting. Finally, once all components have been successfully mapped to their corresponding positions in the template, a fully instantiated product structure object containing concrete content is generated. This object inherits the hierarchical organizational structure of the template and fills in all the details of the specific components, forming a complete, structured configuration scheme that can be directly used for production or release.

[0097] This embodiment obtains specific component entities by parsing recommendation information and merges them with the user's original selections to construct a set to be processed, providing comprehensive raw materials for solution integration. Based on the rules of the associated set, the set undergoes dual verification, automatically identifying internal logical conflicts and structural deficiencies, achieving a deep review of the solution's logical completeness. Pre-set strategies are applied to resolve conflicts and complete dependencies, restoring contradictory intermediate states to a logically self-consistent final component set. Finally, based on the product structure template, the effective component set is instantiated into a complete solution with a clear hierarchy and organization. This process systematically completes the automated and rule-based transformation from scattered component intentions and suggestions to a logically rigorous and structurally complete standardized product solution definition, ensuring the inherent consistency and business compliance of the output solution.

[0098] In one embodiment, step S60 above includes: S601, parse the configuration scheme and extract the combined structure data of all standard components contained in the configuration scheme; S602, based on the mutual exclusion and dependency constraints defined in the component association set, the combined structure data is traversed and compared to identify abnormal conflict items in the configuration scheme that violate the mutual exclusion and dependency constraints; S603, the combined structure data is converted into a feature vector, and the feature vector is input into the component combination analysis model to initiate the second check; S604, Perform multi-dimensional risk analysis on the feature vector using the component combination analysis model, and obtain the model analysis information output by the component combination analysis model; S605, integrate the abnormal conflict items with the model analysis information to generate an inspection result that includes compliance status markers and analysis conclusions.

[0099] In this embodiment, parsing the configuration scheme to extract the combined structure data of all standard components contained therein is a process of deep traversal and information decomposition of the generated, structured product scheme object. The configuration scheme itself is a hierarchical data object, with its root defining the overall product, lower-level nodes representing different chapters or modules, and leaf nodes associated with specific standard components and their parameters. The parsing operation starts from the root node and recursively traverses the entire object tree using a depth-first or breadth-first algorithm. For each traversed node, the system determines whether it is bound to a standard component. The determination is based on whether there is a predefined component reference field in the node data, such as a componentId. When a component node is identified, the parser not only records the unique identifier of the component, but also captures the path information of the node in the tree structure, as well as the instantiation parameters of the component in this scheme. At the same time, the parser records the structural relationships between component nodes, such as the order of sibling nodes and the hierarchy of parent and child nodes. Finally, the parsing outputs an intermediate representation called "composite structure data," which typically consists of two parts: a list of all involved standard component identifiers and their corresponding instance parameters, and a topological graph describing how these components are organized in the scheme.

[0100] The process of traversing and comparing the composite structure data based on the mutual exclusion and dependency constraints defined in the component association set is a static verification of the internal logic of the solution using formal business rules. Verifying mutual exclusion constraints requires checking if there are component pairs marked as mutually exclusive by the association set in the component list. The system loads all edges of type "mutually exclusive" in the association set and establishes a fast lookup hash map for these edges. Then, it traverses the component list in the composite structure data, querying the mutual exclusion map for each component pair. If the query matches, it means the solution violates the mutual exclusion constraint, and the system generates an exception conflict record, including the identifier of the conflicting component pair and the specific rule ID violated. Dependency constraint verification is more complex, requiring verification of whether the solution satisfies all necessary conditions. The system loads all rules of type "dependency," each rule in the form of "If component A exists, then component B must exist." The verification logic traverses each component in the composite structure data as a potential A, searching for all dependency rules that presuppose it, and then checks whether component B in the rule's conclusion also exists in the current component list. If B does not exist, an exception conflict is generated, indicating that component A is missing its dependent component B. The traversal and comparison process needs to efficiently handle a large number of rules and components. This is typically achieved by constructing an index relationship between components and rules, and employing batch processing and pruning strategies to optimize performance.

[0101] Transforming composite structure data into feature vectors is a key feature engineering step in preparing standardized input for component composite analysis models. The transformation process maps non-numerical, structured composite data into a fixed-dimensional real-valued vector. For component composite information, multi-hot encoding is typically used. The system maintains a mapping table from all standard components in the component library to fixed index positions. For each component appearing in the configuration scheme, the feature vector value is set to 1 at its corresponding index position, and the position of components not appearing is set to 0, thus generating a high-dimensional, sparse component existence vector. Component instantiation parameters, such as coverage amount and deductible, need to be normalized and then concatenated as an independent dimension into the feature vector. Furthermore, the topological relationship information in the composite structure data also needs to be encoded. One approach is to transform the structural relationships into graph features, such as calculating the number of components in the scheme, the maximum nesting depth, and the proportion of components in different functional categories, adding these as new dimensions. Finally, all these processed values ​​are concatenated into a one-dimensional feature vector, which serves as a numerical "fingerprint" of the entire configuration scheme.

[0102] Component-based risk analysis, which uses a component-based combinatorial analysis model to perform multi-dimensional risk analysis on feature vectors to obtain model analysis information, is a process of predictively evaluating solutions using a pre-trained complex function. The component-based combinatorial analysis model here is a deep neural network with an architecture specifically designed to handle high-dimensional sparse features and output multi-dimensional risk assessments. The input layer receives the aforementioned feature vectors. Since the vectors contain sparse component existence encodings, the model first passes through an embedding layer, mapping the existence signal of each component to a low-dimensional dense vector representation. These embedding vectors are then weighted and aggregated through an attention mechanism layer, which learns the importance of different components in the current combination to the overall risk. The aggregated representation is concatenated with other dense features and input to subsequent fully connected layers. The network contains multiple hidden layers, each undergoing linear transformation, batch normalization, and introducing non-linearity using the ReLU activation function. The model's output layer is not a single neuron but rather multiple output heads connected in parallel, each responsible for predicting a risk indicator in a specific dimension. For example, in the medical, financial, and insurance scenarios, the output heads could correspond to "expected claim rate," "estimated average payout amount," "probability of triggering high-risk customers," and "market competitiveness score," respectively. Each output head uses an appropriate activation function. When the feature vectors are input into the model, the data flows through the network, ultimately producing a set of numerical outputs that constitute the model's analytical information.

[0103] Integrating anomaly / conflict information with model analysis information to generate an inspection result containing compliance status markers and analysis conclusions is a process of information fusion and decision support report generation. The integration logic first determines the hard compliance status of the solution based on anomaly / conflict information. If no anomaly / conflict information is found, the compliance status is marked as "Pass"; otherwise, it is marked as "Fail," and a detailed list of all conflicts is attached. For model analysis information, the system compares the output value of each dimension with a preset threshold range to generate a set of evaluation conclusions. For example, if the "Expected Claims Rate" output value is 0.15, and the preset threshold range is [0, 0.1], a conclusion is generated: "Expected Claims Rate Exceeds the Safety Threshold." The system then organizes these two parts of information into a structured inspection result object. This object contains an overall summary, compliance status, a detailed list of anomaly / conflict information, and a list of multi-dimensional model analysis conclusions. Furthermore, a comprehensive risk score or priority identifier can be calculated for the inspection result based on business rules. This result object can be serialized into a standard format for display on the user interface or to trigger subsequent automated workflows.

[0104] This embodiment, by analyzing the solution and performing rigorous rule comparisons based on the association set, can automatically and comprehensively identify hard compliance issues that violate established business logic, ensuring that the solution meets all mandatory constraints. Simultaneously, by transforming the solution into a feature vector and inputting it into an AI model for multi-dimensional analysis, it can leverage data-driven intelligent prediction to reveal potential performance and problems in soft indicators such as risk, cost, and market adaptability. Finally, the deterministic issues of rule checking and the predictive issues of model analysis are integrated into a unified inspection report, providing a comprehensive and hierarchical quality assessment from compliance to risk. This dual-check mechanism greatly enhances the depth, objectivity, and efficiency of solution review.

[0105] In one embodiment, a configuration scheme generation apparatus for component products is provided, which corresponds one-to-one with the configuration scheme generation method for component products described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the configuration scheme generation device for component products of the present invention. The modules include a component modeling module 10, an association learning module 20, a visualization configuration module 30, an intelligent recommendation module 40, a scheme assembly module 50, a dual verification module 60, and a release control module 70. Detailed descriptions of each functional module are as follows: The component modeling module 10 is used to acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library. The association learning module 20 is used to acquire historical business data, determine the association relationship between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data. The visualization configuration module 30 is used to display the standard components in the component library through a visualization interface and receive component selection instructions, and form component selection combinations based on the component selection instructions; The intelligent recommendation module 40 is used to generate component recommendation information based on the component selection combination and the component association set through the component combination analysis model; The scheme assembly module 50 is used to process the component selection and combination to form a configuration scheme based on the component recommendation information and the component association set. The dual verification module 60 is used to perform a first check on the configuration scheme based on the component association set, and a second check on the configuration scheme through the component combination analysis model, and generate a check result; The release control module 70 is used to release the configuration scheme when the inspection result indicates that release is allowed.

[0106] Specific limitations regarding the configuration scheme generation device for component products can be found in the aforementioned limitations on the configuration scheme generation method for component products, and will not be repeated here. Each module in the aforementioned configuration scheme generation device for component products can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0107] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a configuration scheme generation method for a component product on the server side.

[0108] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a component product configuration scheme generation method.

[0109] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library; Acquire historical business data, determine the relationships between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data; The standard components in the component library are displayed through a visual interface, and component selection instructions are received. Based on the component selection instructions, component selection combinations are formed. Based on the selected component combination and the associated component set, component recommendation information is generated through the component combination analysis model. Based on the component recommendation information and the component association set, the component selection and combination are processed to form a configuration scheme; The configuration scheme is first checked based on the component association set, and then a second check is performed on the configuration scheme through the component combination analysis model to generate the check results. When the inspection results indicate that publication is permitted, the configuration scheme is published.

[0110] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library; Acquire historical business data, determine the relationships between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data; The standard components in the component library are displayed through a visual interface, and component selection instructions are received. Based on the component selection instructions, component selection combinations are formed. Based on the selected component combination and the associated component set, component recommendation information is generated through the component combination analysis model. Based on the component recommendation information and the component association set, the component selection and combination are processed to form a configuration scheme; The configuration scheme is first checked based on the component association set, and then a second check is performed on the configuration scheme through the component combination analysis model to generate the check results. When the inspection results indicate that publication is permitted, the configuration scheme is published.

[0111] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0112] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0114] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0115] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for generating a configuration scheme for a component product, characterized in that, Includes the following steps: Acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library; Acquire historical business data, determine the relationships between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data; The standard components in the component library are displayed through a visual interface, and component selection instructions are received. Based on the component selection instructions, component selection combinations are formed. Based on the selected component combination and the associated component set, component recommendation information is generated through the component combination analysis model. Based on the component recommendation information and the component association set, the component selection and combination are processed to form a configuration scheme; The configuration scheme is first checked based on the component association set, and then a second check is performed on the configuration scheme through the component combination analysis model to generate the check results. When the inspection results indicate that publication is permitted, the configuration scheme is published.

2. The method for generating configuration schemes for component products as described in claim 1, characterized in that, Acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in a component library, including: Historical product data is acquired, and document layout recognition and noise removal are performed on the historical product data to generate cleaned historical product data. The cleaned historical product data is then parsed to determine the text paragraph hierarchy structure. Based on the text paragraph hierarchy, key entity identification is performed on the cleaned historical product data to extract product element information including functional description, execution conditions, exclusion restrictions and numerical factors. The product element information is mapped to a preset standard data model, attribute labels and identifiers are assigned to the mapped product element information, and the attribute labels, identifiers and mapped product element information are combined into a standard component with independent semantics. The functional category of the standard component is determined based on the identifier and the attribute label; Standard components whose function category is basic information are stored in the basic information field of the component library; standard components whose function category is core function are stored in the core function field of the component library; standard components whose function category is value-added service are stored in the value-added service field of the component library; and standard components whose function category is adjustment factor are stored in the adjustment factor field of the component library.

3. The method for generating configuration schemes for component products as described in claim 1, characterized in that, Acquire historical business data, determine the relationships between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data, including: Acquire historical business data, and extract product configuration samples containing standard components from the component library from the historical business data; Analyze the co-occurrence frequency of different standard components in the product configuration sample to determine the dependency and conflict relationships between the standard components; The dependencies and conflicts are stored as a structured mapping file to generate a set of component associations; The operational indicator data corresponding to the product configuration sample is obtained from the historical business data, and the standard component combination in the product configuration sample is associated with the corresponding operational indicator data to construct a training dataset. With the goal of analyzing the operating indicators corresponding to the standard component combination, the training dataset is used to perform machine learning to generate a component combination analysis model.

4. The method for generating configuration schemes for component products as described in claim 1, characterized in that, The system displays standard components from the component library through a visual interface and receives component selection instructions. Based on these instructions, it forms component selection combinations, including: Standard components are extracted from the basic information domain, core function domain, value-added service domain, and adjustment factor domain of the component library; The extracted standard components are graphically rendered in a visual interface using a tree structure or matrix view; The visual interface captures click operations on the graphically rendered standard components and obtains component selection instructions containing the standard component's identity identifier. Extract the standard component identity identifier from the component selection instruction, and obtain the attribute data of the selected standard component corresponding to the identity identifier from the component library; The selected standard components are structurally encapsulated according to the attribute data to form a component selection combination.

5. The method for generating configuration schemes for component products as described in claim 1, characterized in that, Based on the selected component combination and the associated component set, component recommendation information is generated through the component combination analysis model, including: Analyze the component selection combination to determine the standard components already included in the component selection combination; The included standard components are compared with the component association set to determine necessary supplementary components that have a dependency relationship with the included standard components and are outside the component selection combination; Based on the component association set and the component selection combination, candidate completion components are determined from the component library as feature completion items; Input the selected component combination, the necessary supplementary components, and the feature completion items into the component combination analysis model; The component combination analysis model is used to perform multi-dimensional analysis on the component selection and combination, the necessary supplementary components, and the feature completion items to determine the degree of correlation of each feature completion item. The necessary supplementary components and feature completion items whose relevance meets the preset filtering conditions are integrated to generate component recommendation information.

6. The method for generating configuration schemes for component products as described in claim 1, characterized in that, Based on the component recommendation information and the component association set, the component selection and combination are processed to form a configuration scheme, including: Parse the component recommendation information to obtain the recommended components contained in the component recommendation information; The recommended components and the component selection combinations are merged to construct a temporary candidate component set; The temporary candidate component set is verified based on the mutual exclusion constraints and dependency conditions defined in the component association set, and conflicting components and missing dependent components in the temporary candidate component set are identified. The conflicting components are processed based on a preset conflict resolution strategy, and the missing dependent components are supplemented to determine the final set of valid components. Obtain a preset product structure template, map the standard components in the final effective component set to the corresponding nodes of the product structure template, and generate a configuration scheme with a hierarchical structure.

7. The method for generating configuration schemes for component products as described in claim 1, characterized in that, The configuration scheme is first checked based on the component association set, and then a second check is performed on the configuration scheme using the component combination analysis model, generating check results, including: Parse the configuration scheme and extract the combined structure data of all standard components contained in the configuration scheme; The composite structure data is traversed and compared according to the mutual exclusion and dependency constraints defined in the component association set to identify abnormal conflict items in the configuration scheme that violate the mutual exclusion and dependency constraints; The combined structure data is converted into a feature vector, and the feature vector is input into the component combination analysis model to initiate the second check; The component combination analysis model is used to perform multi-dimensional risk analysis on the feature vector to obtain the model analysis information output by the component combination analysis model. By integrating the aforementioned abnormal conflict items with the model analysis information, an inspection result containing compliance status markers and analysis conclusions is generated.

8. A configuration scheme generation device for a component product, characterized in that, The configuration scheme generation device for the component product includes: The component modeling module is used to acquire historical product data, parse and process the historical product data, extract product element information, convert the product element information into standard components, and store the standard components in the component library. The association learning module is used to acquire historical business data, determine the association relationship between standard components based on the historical business data and standard components in the component library, generate a component association set, and construct a component combination analysis model based on the historical business data. The visualization configuration module is used to display the standard components in the component library through a visual interface and receive component selection instructions, and form component selection combinations based on the component selection instructions. The intelligent recommendation module is used to generate component recommendation information based on the component selection combination and the component association set through the component combination analysis model; The scheme assembly module is used to process the component selection and combination to form a configuration scheme based on the component recommendation information and the component association set; The dual verification module is used to perform a first check on the configuration scheme based on the component association set, and a second check on the configuration scheme through the component combination analysis model, and generate a check result; The release control module is used to release the configuration scheme when the inspection result indicates that release is allowed.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a component product configuration scheme generation program stored in the memory and executable on the processor. When the component product configuration scheme generation program is executed by the processor, it implements the steps of the component product configuration scheme generation method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a configuration scheme generation program for component products. When the configuration scheme generation program for component products is executed by a processor, it implements the steps of the configuration scheme generation method for component products as described in any one of claims 1-7.

Images