Data intellectual property structured generation method and system based on large model cognitive intelligent discovery

Abstract

The invention discloses a data intellectual property structured generation method and system based on large model cognitive intelligent discovery, and the method comprises the steps: extracting registered data intellectual property information, and carrying out the structured processing to generate standardized knowledge entries; converting the standardized knowledge entries into high-dimensional vector representation by using an embedded model, and constructing a professional knowledge base; generating a query vector based on the feature information of the to-be-processed data file, and obtaining a related case set from a professional knowledge base through vector similarity retrieval; performing multi-dimensional fusion on the related case set and the input data features to generate a data intellectual property application material; the application material is automatically verified, a data processing algorithm in the application material is executed, and a structured registration application is submitted to an intellectual property platform after it is ensured that codes are correctly operated through a self-healing execution mechanism. By utilizing the embodiment of the invention, the registration efficiency and the material normalization can be improved, and meanwhile, the accuracy and the performability of the technical content are ensured.

Description

Technical Field

[0001] This invention belongs to the field of large model technology, and in particular to a method and system for generating structured data intellectual property based on large model cognitive intelligence discovery. Background Technology

[0002] As a new factor of production, the importance of data intellectual property protection and value realization is increasingly prominent. Currently, the registration and application process for data intellectual property rights mainly relies on manual drafting of application materials, resulting in inefficiency and insufficient standardization. Although some automated tools have been developed to assist in text generation, they often lack a deep understanding of the technical implications of data algorithms, leading to deficiencies in the technical accuracy and legal rigor of the generated application materials. Furthermore, existing methods lack the large-scale and structured utilization of historically registered cases, failing to provide accurate references and guidance for the generation of new materials, resulting in inconsistent application quality and hindering review efficiency. Summary of the Invention

[0003] The purpose of this invention is to provide a data intellectual property structure generation method and system based on large-scale model cognitive intelligence discovery, in order to overcome the shortcomings of the existing technology, improve registration efficiency and material standardization, and at the same time ensure the accuracy and executability of the technical content.

[0004] One embodiment of this application provides a method for generating structured data intellectual property rights based on large-model cognitive intelligence discovery, the method comprising: The data acquisition layer extracts registered intellectual property information from multiple data sources and performs structured processing on the information based on predefined templates to generate standardized knowledge entries. The standardized knowledge items are converted into high-dimensional vector representations using an embedding model, and a professional knowledge base with a parent-child document association architecture is constructed, wherein the child documents focus on specific knowledge dimensions while the parent documents maintain complete case information; A query vector is generated based on the feature information of the data file to be processed. A set of relevant cases is obtained from the professional knowledge base through vector similarity retrieval, and the matching degree score between each case and the features of the input data is calculated. The relevant case set is fused with the input data features in multiple dimensions, and the large language model is guided to generate data intellectual property application materials containing algorithm rule descriptions and executable code through preset multi-round prompt templates. The generated application materials are automatically verified and the data processing algorithms are executed. After ensuring the correct operation of the code through a self-healing execution mechanism, a structured registration application is submitted to the intellectual property platform.

[0005] Another embodiment of this application provides a data intellectual property structure generation system based on large-model cognitive intelligence discovery, the system comprising: The extraction module is used to extract registered intellectual property information from multiple data sources through the data acquisition layer, and to perform structured processing on the information based on a predefined template to generate standardized knowledge entries; The conversion module is used to convert the standardized knowledge items into high-dimensional vector representations using an embedding model, and to construct a professional knowledge base with a parent-child document association architecture, wherein the child documents focus on specific knowledge dimensions while the parent documents maintain complete case information; The acquisition module is used to generate query vectors based on the feature information of the data file to be processed, retrieve relevant case sets from the professional knowledge base through vector similarity retrieval, and calculate the matching degree score between each case and the input data features; The generation module is used to fuse the relevant case set with the input data features in multiple dimensions, and guide the large language model to generate data intellectual property application materials containing algorithm rule descriptions and executable code through preset multi-round prompt templates; The execution module is used to automatically verify the generated application materials and execute the data processing algorithms therein. After ensuring that the code runs correctly through a self-healing execution mechanism, it submits the structured registration application to the intellectual property platform.

[0006] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0007] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0008] Compared with existing technologies, the present invention provides a data intellectual property structure generation method based on large-scale model cognitive intelligence discovery, which can improve registration efficiency and material standardization, while ensuring the accuracy and executability of technical content. Attached Figure Description

[0009] Figure 1 A hardware structure diagram of a computer terminal for a data intellectual property structure generation method based on large model cognitive intelligence discovery, provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a data intellectual property structure generation method based on large-model cognitive intelligence discovery, provided in an embodiment of the present invention; Figure 3This is a schematic diagram of a data intellectual property structure generation system based on large model cognitive intelligence discovery, provided as an embodiment of the present invention. Detailed Implementation

[0010] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0011] This invention first provides a data intellectual property structure generation method based on large-scale model cognitive intelligence discovery. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0012] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure diagram of a computer terminal for a data intellectual property structure generation method based on large-model cognitive intelligence discovery, provided as an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0013] See Figure 2 The embodiments of the present invention provide a method for generating structured data intellectual property based on large-model cognitive intelligence discovery, which may include the following steps: S201, the data acquisition layer extracts registered data intellectual property information from multiple data sources, and performs structured processing on the information based on a predefined template to generate standardized knowledge entries; Specifically, multiple heterogeneous data sources can be connected through a distributed data acquisition interface to automatically extract the original records of successfully registered data intellectual property rights and generate a multi-source original data set; This step is fundamental to acquiring data intellectual property information. Its core is to break down barriers between heterogeneous data sources through a flexible and adaptable collection interface, comprehensively extracting the registered original information to provide a complete data source for subsequent structured processing. The specific implementation method is as follows: The distributed data acquisition interface adopts a "master-slave architecture + multi-protocol adaptation" design. The master node is responsible for task scheduling and data aggregation, while slave nodes deploy dedicated acquisition modules according to data source type. It supports multiple mainstream data transmission protocols such as RESTAPI, WebService, JDBC, and FTP, and can simultaneously connect to multiple heterogeneous data sources, including the State Intellectual Property Office's public database, local intellectual property registration platforms, enterprise internal data asset registration systems, and industry association intellectual property filing databases. For example, when connecting to the State Intellectual Property Office's public database, the RESTAPI interface is used to call its open data service, with request parameters including "data type = data intellectual property", "registration status = registered", and "time range = last 5 years". The interface returns raw records in JSON format. When connecting to an enterprise's internal Oracle database, the JDBC interface executes the query statement "SELECT * FROM data_ip WHERE register_status = 'registered'" to extract structured data table records. When connecting to an industry association's FTP server, the CSV format filing data file is downloaded via a file transfer protocol.

[0014] During the automatic extraction process, a "field mapping table" is used for initial adaptation to address the differences in record formats across different data sources. This mapping table predefines the correspondence between fields from each data source and common fields. For example, the "application number" in the State Intellectual Property Office database corresponds to the common field "Intellectual Property Identifier ID," the "data asset name" in an enterprise's internal system corresponds to the common field "data name," and the "technical solution summary" in the industry association's filing database corresponds to the common field "algorithm rule description." The extracted raw records contain rich core information. For instance, a record obtained from the State Intellectual Property Office might read: "Application Number: 202510012345.6; Data Name: E-commerce Recommendation Data Based on User Behavior; Registration Date: 2025-03-15; Ownership: XX Technology Co., Ltd.; Data Type: Structured Data; Technical Solution Summary: This data is based on a collaborative filtering algorithm, collecting user browsing, collection, and purchase behavior data to construct a user-product rating matrix, achieving personalized recommendations through matrix decomposition; Application Scenario: E-commerce platform product recommendation; Registration Status: Registered."

[0015] The generated multi-source raw data set is stored in a structured format of "data source identifier - original record - collection timestamp". Each record retains dual identifiers: original fields and general fields. For example, the data source identifier is "State Intellectual Property Office API", and the collection timestamp is "2025-11-05 10:30:22", ensuring data traceability. The set supports an incremental collection mechanism, where each collection only extracts newly registered records added after the previous collection time point, avoiding duplicate collection. For example, the initial collection covers all records from 2020 to 2025, and subsequent daily collections only extract records added the previous day, improving collection efficiency.

[0016] The multi-source raw data set is cleaned and formatted. A rule-based data verification algorithm is used to remove duplicate records and correct format errors, generating a cleaned data set. This step improves data quality through data cleaning and format standardization. The core of this step is to use rule-based validation algorithms to eliminate duplicates and correct errors, ensuring data accuracy and consistency. The specific implementation method is as follows: The rule-based data validation algorithm comprises two parts: duplicate record removal rules and format error correction rules. The duplicate record removal rules use "Intellectual Property Identifier ID" and "Data Name + Ownership" as dual unique keys. For example, if two records both have "202510012345.6" as their "Intellectual Property Identifier ID," or if "Data Name = E-commerce Recommendation Data Based on User Behavior" and "Ownership = XX Technology Co., Ltd.", they are considered duplicate records. The record with the most recent collection time and the most complete fields is retained, while the remaining duplicate entries are deleted. For instance, if a multi-source raw dataset contains two duplicate records from different data sources—one from the State Intellectual Property Office API (collection time 2025-11-05) containing 10 fields, and the other from an internal enterprise system (collection time 2025-11-04) containing 8 fields—then the former is retained, and the latter is deleted.

[0017] The formatting error repair rules have specific repair logic for different types of fields such as date, numeric, and text: Date fields are uniformly standardized to the format "YYYY-MM-DD", for example, "2025 / 03 / 15", "2025.3.15", and "20250315" are corrected to "2025-03-15" respectively; Numeric fields are uniformly retained to two decimal places, for example, "1 million", "1000000", and "1000000.0" are uniformly corrected to "1000000.00"; Text fields are removed of extra spaces and special characters (such as newline characters and tab characters), for example, "based on collaborative filtering algorithm\n to implement e-commerce recommendation" is corrected to "based on collaborative filtering algorithm to implement e-commerce recommendation"; Enumerated type fields (such as data type and registration status) are uniformly standardized, for example, "structured" and "structured data" are uniformly unified to "structured data", and "registered" and "registered" are uniformly unified to "registered".

[0018] During data cleaning, data validity checks are performed simultaneously, and invalid records are removed. For example, records with missing or incorrectly formatted "Intellectual Property Identifier ID" (not in the format of "year + serial number + decimal point + check digit"), empty "data name", or "registration date" outside a reasonable range (e.g., earlier than 2010 or later than the current date) are all deemed invalid and deleted. For instance, a record with "Intellectual Property Identifier ID" as "2025abc123" is not formatted correctly and is directly deleted; a record with "registration date" as "2030-01-01" is outside a reasonable range and is also deleted.

[0019] In the cleaned dataset, the percentage of duplicate records decreased from 15% to below 1% of the original dataset, the format error rate decreased from 20% to below 0.5%, all invalid records were removed, and the fields of each record were formatted uniformly and the information was complete. For example, the cleaned record is as follows: "Intellectual Property Identifier ID: 202510012345.6; Data Name: E-commerce Recommendation Data Based on User Behavior; Registration Date: 2025-03-15; Ownership: XX Technology Co., Ltd.; Data Type: Structured Data; Algorithm Rule Description: Based on collaborative filtering algorithm, collect user browsing, collection, and purchase behavior data, construct user-product rating matrix, and achieve personalized recommendations through matrix decomposition; Application Scenario: E-commerce platform product recommendation; Registration Status: Registered; Collection Timestamp: 2025-11-05 10:30:22; Data Source Identifier: State Intellectual Property Office API".

[0020] Based on a predefined structured template, each record in the cleaned dataset is mapped to a standardized field to generate preliminary structured data; This step achieves standardized data mapping through structured templates. Its core is to unify the purified heterogeneous data into a fixed, standardized field system, laying the foundation for subsequent knowledge entry generation. The specific implementation method is as follows: The predefined structured template is designed based on the core attributes and registration specifications of data intellectual property rights. It includes 12 required standardized fields and 3 optional standardized fields. The required fields are: [Unique Intellectual Property Identifier], [Data Name], [Data Source], [Data Type], [Data Scale], [Ownership], [Registration Date], [Algorithm Rule Description], [Core Technical Indicators], [Application Scenarios], [Data Security Level], and [Registration Status]. The optional fields are: [Partnering Units], [Technology Transfer Status], and [Related Patent IDs]. Each field clearly defines its field definition, data type, value range, and format requirements. For example, the definition of

Data Type

Core Technical Indicators

Data Security Level

[0021] The field mapping process is executed according to the logic of "one-to-one mapping + many-to-one integration + text extraction": For fields in the cleaned data that directly correspond to the standardized fields, a one-to-one mapping is performed. For example, "Intellectual Property Identifier ID" is directly mapped to [Intellectual Property Unique Identifier], and "Data Name" is directly mapped to [Data Name]. For information scattered across multiple fields, many-to-one integration is performed. For example, the contents of the two fields "Technical Solution Summary" and "Algorithm Detail Description" are integrated and mapped to [Algorithm Rule Description]. For information in the cleaned data that is not directly provided but is a required field, text extraction technology is used to extract it from the relevant fields. For example, core technical indicators are extracted from [Algorithm Rule Description], and the data security level is inferred from [Application Scenarios].

[0022] For example, a piece of purified data contains "Intellectual Property Identifier ID: 202510012345.6; Data Name: E-commerce Recommendation Data Based on User Behavior; Data Source: E-commerce Platform User Behavior Logs; Data Type: Structured Data; Data Volume: 5 million records; Ownership: XX Technology Co., Ltd.; Registration Date: 2025-03-15; Technical Solution Summary: Based on collaborative filtering algorithm, collect user browsing, collection, and purchase behavior data, construct a user-product rating matrix, and achieve personalized recommendations through matrix decomposition, with a recommendation accuracy of 85% and a recall rate of 78%; Application Scenario: E-commerce platform product recommendation; Registration Status: Registered". After mapping to a structured template, the initial structured data generated is: [Unique Intellectual Property Identifier]: 20251001234 5.6; [Data Name]: E-commerce recommendation data based on user behavior; [Data Source]: User behavior logs of e-commerce platforms; [Data Type]: Structured data; [Data Scale]: 5 million records; [Ownership]: XX Technology Co., Ltd.; [Registration Date]: 2025-03-15; [Algorithm Rule Description]: Based on collaborative filtering algorithm, collect user browsing, collection, and purchase behavior data, construct user-product rating matrix, and achieve personalized recommendations through matrix decomposition; [Core Technical Indicators]: Recommendation accuracy: 85%; Recall rate: 78%; [Application Scenarios]: Product recommendation on e-commerce platforms; [Data Security Level]: Level 2 (medium-low risk); [Registration Status]: Registered; [Partner Units]: None; [Technology Transfer Status]: None; [Related Patent IDs]: None.

[0023] The generated preliminary structured data is organized in a standardized field order. The field integrity of each record is ≥95%, and the field format fully conforms to the template requirements. Records from different data sources form a unified structural specification. For example, records from internal enterprise systems and records from public databases both contain the same 15 standardized fields, providing a unified processing basis for subsequent semantic integrity verification.

[0024] The initial structured data is semantically validated, and missing fields are detected and necessary information is automatically added using natural language processing technology, ultimately generating a standardized set of knowledge entries.

[0025] This step improves the structured data through semantic verification and information supplementation. The core is to use natural language processing technology to address the issue of missing fields in the initial structured data, ensuring the semantic integrity of knowledge entries. The specific implementation method is as follows: Semantic integrity verification employs a two-step approach: "field missing detection + semantic rationality verification." First, it iterates through the 12 required fields of each preliminary structured data entry, marking missing fields (e.g., "[Data Security Level]" is not filled in, "[Core Technical Indicators]" is empty). Then, it performs semantic rationality verification on the filled fields. For example, when the "[Data Type]" is "structured data," it checks whether the "[Data Scale]" is in numerical + unit format, whether the "[Algorithm Rule Description]" contains at least one explicit algorithm name, and whether the "[Application Scenario]" is consistent with the data type and algorithm rule logic (e.g., the application scenario for structured data should not be "unstructured text sentiment analysis").

[0026] Natural Language Processing (NLP) technology comprises three core capabilities: Named Entity Recognition (NER), text classification, and keyword extraction. These capabilities are used to automatically fill in missing fields. For example, if the "Data Security Level" is missing, the semantics of the "Application Scenario" and "Algorithm Rule Description" are analyzed using a text classification model to determine if the data involves sensitive information such as personal privacy or trade secrets. For instance, if the application scenario is "financial risk control" and the algorithm rule description involves "user credit data," the "Data Security Level" is automatically filled in as "Level 3 (Medium-High Risk)." For example, if the "Core Technical Indicators" are missing, performance-related keywords are extracted from the "Algorithm Rule Description" using keyword extraction technology. For instance, from "This data uses the K-means clustering algorithm, with a clustering purity of 92% and a running time ≤ 5 minutes," "Clustering purity: 92%; Running time: ≤ 5 minutes" is extracted and added to the "Core Technical Indicators." Finally, if the "Data Source" is missing, the data-generating entity is identified from the "Application Scenario" using NER. For instance, if the application scenario is "hospital patient medical record management," the "Data Source" is automatically filled in as "hospital electronic medical record system."

[0027] During the information supplementation process, missing fields that cannot be automatically supplemented using natural language processing technology (such as the "Related Patent Association ID") are marked as "To be supplemented," and supplementation prompts are generated, such as "Please supplement the patent authorization number related to the intellectual property rights of this data." However, this does not affect the generation of standardized knowledge entries; it only prompts for improvement during subsequent manual review. For example, if the "Core Technical Indicators" of a preliminary structured data entry are missing, and the "Algorithm Rule Description" is "Based on the decision tree algorithm, customer credit risk is assessed, with a model accuracy exceeding 90% and a false positive rate below 5%," the "Core Technical Indicators" are supplemented through keyword extraction as "Accuracy: >90%; False Positive Rate: <5%." If the "Data Security Level" is missing, it is supplemented as "Level 3 (Medium-High Risk)" by analyzing the data through a text classification model to determine if it involves customer credit information.

[0028] The generated standardized knowledge entry set contains complete standardized field information for each record, with a field missing rate reduced to below 0.3% and semantic rationality exceeding 99%. The format of knowledge entries is uniformly "Knowledge Entry ID - Standardized Field Set - Semantic Validation Result", for example: "Knowledge Entry ID: KID20251105001; [Unique Intellectual Property Identifier]: 202510012345.6; [Data Name]: E-commerce Recommendation Data Based on User Behavior; [Data Source]: E-commerce Platform User Behavior Logs; [Data Type]: Structured Data; [Data Scale]: 5 million records; [Ownership of Rights]..." [Registration Date]: XX Technology Co., Ltd.; [Algorithm Rule Description]: Based on collaborative filtering algorithm, it collects user browsing, collection, and purchase behavior data, constructs a user-product rating matrix, and achieves personalized recommendations through matrix decomposition; [Core Technical Indicators]: Recommendation accuracy: 85%; Recall rate: 78%; [Application Scenarios]: Product recommendation on e-commerce platforms; [Data Security Level]: Level 2 (medium-low risk); [Registration Status]: Registered; [Partner Units]: None; [Technology Transfer Status]: None; [Related Patent IDs]: To be supplemented; Semantic verification result: Complete and reasonable. This set provides a high-quality, standardized knowledge foundation for subsequent embedded model conversion and knowledge base construction.

[0029] S202, The standardized knowledge items are converted into high-dimensional vector representations using an embedding model to construct a professional knowledge base with a parent-child document association architecture, wherein the child documents focus on specific knowledge dimensions while the parent documents maintain complete case information; Specifically, the BGE-M3 embedding model can be used to convert each item in the standardized knowledge item set into a multi-dimensional vector representation, generating a knowledge item vector set; This step is the core vectorization process in knowledge base construction. Its core is to transform structured textual knowledge into computer-computable high-dimensional vectors using a high-performance embedding model, preserving semantic information and feature associations, thus providing a foundation for subsequent similarity retrieval. The specific implementation method is as follows: BGE-M3 (BAAI GeneralEmbeddingModel3) was selected as the core embedding model. This model is specifically optimized for embedding professional domain knowledge, supports multilingual and multi-granular semantic representation, and its vector dimensions can be flexibly configured (512-dimensional, 768-dimensional, and 1024-dimensional). Here, 1024-dimensional vector output was chosen to balance semantic expressiveness and storage efficiency. A pre-trained large version of checkpoint was used for model loading. This version achieves a semantic similarity calculation accuracy of over 92% on professional texts (such as technical documents and intellectual property application materials), making it suitable for the dense use of professional terminology in the field of intellectual property data.

[0030] The parameters for the embedding transformation have been specifically optimized: the batch size is set to 32 to balance processing efficiency and memory usage (32 knowledge items are processed in a single batch, with memory usage ≤8GB); the text truncation length is set to 512 characters to ensure complete coverage of the core fields of the knowledge items (avoiding the loss of key information due to excessively long text); the normalization parameter is set to True to normalize the output vector to the [-1,1] interval, which facilitates subsequent cosine similarity calculation.

[0031] Taking a typical entry from the standardized knowledge entry set as an example (knowledge entry ID: KID20251105001), its core text content is: "Data name: e-commerce recommendation data based on user behavior; data type: structured data; data scale: 5 million entries; ownership: XX Technology Co., Ltd.; algorithm rule description: based on collaborative filtering algorithm, collect user browsing, collection, and purchase behavior data, construct user-product rating matrix, and achieve personalized recommendation through matrix decomposition; core technical indicators: recommendation accuracy 85%, recall 78%; application scenario: e-commerce platform product recommendation; data security level: level 2 (medium-low risk)." Concatenate the entry into a complete text string in the format "field name: field value" and input it into the model. The output is a 1024-dimensional vector. Some vector values ​​are as follows: [0.0342, -0.0125, 0.0568, -0.0431, 0.0297, ..., -0.0089] (The vector values ​​are rounded to four decimal places and are generally distributed in the range of -0.1 to 0.1. The absolute values ​​of the core semantic-related dimensions are relatively large, such as the dimension values ​​of "collaborative filtering" and "e-commerce recommendation" being 0.0782 and 0.0654, respectively).

[0032] The generated knowledge entry vector set is stored in a structured format of "knowledge entry ID - 1024-dimensional vector - metadata tag". The metadata tag contains core attributes such as data type, application scenario, and algorithm category (e.g., tags: "structured data | e-commerce | collaborative filtering algorithm"), facilitating multi-dimensional filtering based on tags during subsequent retrieval. The vector set supports incremental updates; when a new knowledge entry is added, only the new entry undergoes embedding transformation, and is associated with the original set through the knowledge entry ID, ensuring the dynamic expansion capability of the knowledge base.

[0033] For each knowledge item, multiple sub-documents are created according to predefined knowledge dimension division rules. Each sub-document focuses on a specific dimension, including data structure, application scenario or algorithm rules, generating a dimensional sub-document set. This step achieves refined organization of knowledge through dimensional decomposition. The core is to break down complete knowledge entries into sub-documents focusing on a single topic according to professional dimensions. This preserves fine-grained features while providing precise entry points for multi-dimensional retrieval. The specific implementation method is as follows: The predefined knowledge dimension division rules are designed based on the core attributes of data intellectual property rights and retrieval needs. They specify three mandatory dimensions and one optional dimension. The mandatory dimensions are data structure, application scenario, and algorithm rules. The optional dimension is ownership (which can be flexibly activated according to actual needs). The division criteria and included content of each dimension are clearly defined: Data structure dimension: Focusing on the physical and logical structural characteristics of data, it includes five subfields: data type, field name and data type, data size, storage format, and field constraints. Its core function is to support retrieval needs related to "data form" (such as "finding structured user behavior data with 5 million records"). Application Scenario Dimension: Focusing on the actual application characteristics of data, it includes four sub-fields: industry sector, specific use case, target user group, and commercial value manifestation. Its core function is to support retrieval needs related to "application scenario matching" (such as "finding data on product recommendation scenarios in the e-commerce sector"). Algorithm rules dimension: Focusing on the technical characteristics of data processing, it includes four sub-fields: core algorithm name, technical indicator parameters, algorithm implementation logic, and data processing flow. Its core function is to support retrieval needs related to "technical solution matching" (such as "finding recommendation data based on collaborative filtering algorithm").

[0034] The creation of dimensional sub-documents follows the principle of "one dimension, one sub-document." Each sub-document is assigned a unique identifier (DocumentID, or DID for short). The identifier naming rule is "DID-dimensional abbreviation-date-serial number," where the dimension abbreviations are DS (data structure), AS (application scenario), and AR (algorithm rule), respectively. Taking knowledge entry KID20251105001 as an example, it is split into three sub-documents: Data structure sub-document (DID-DS20251105001): "Data type: Structured data; Field names and data types: User ID (string), Product ID (string), Browsing duration (numeric, unit: seconds), Favorites identifier (Boolean), Purchase identifier (Boolean); Data size: 5 million records; Storage format: Parquet; Field constraints: User ID is not null, Browsing duration ≥ 0"; Application Scenario Sub-document (DID-AS20251105001): "Industry: E-commerce; Specific Use Case: Personalized product recommendation on the platform; Target User Group: Registered users of the e-commerce platform; Business Value: Increases product exposure by 30% and increases user repurchase rate by 15%"; Algorithm rules sub-document (DID-AR20251105001): "Core algorithm name: Collaborative filtering algorithm (user-based collaborative filtering + matrix factorization); Technical indicators: Recommendation accuracy 85%, recall 78%, matrix factorization iterations 100 times, similarity calculation method: Pearson correlation coefficient; Algorithm implementation logic: 1. Collect user behavior data to construct a user-item interaction matrix; 2. Fill missing values ​​in the matrix (using mean filling); 3. Map user vectors and item vectors to a 50-dimensional latent semantic space through matrix factorization; 4. Calculate the similarity between users and generate a Top-N recommendation list; Data processing flow: Data collection → Data cleaning → Matrix construction → Model training → Recommendation generation."

[0035] The generated collection of dimensional sub-documents is stored according to the dimensional type. Each sub-document contains five fixed fields: "sub-document ID, parent knowledge entry ID, dimensional type, sub-document content, and creation timestamp". This ensures that the sub-document can be traced back to the original knowledge entry, laying the foundation for subsequent parent-child association.

[0036] Create a corresponding parent document for each knowledge item. The parent document integrates the content of all child documents and maintains complete case information. Establish the relationship between parent and child documents through a unique identifier to generate a parent-child document system. This step achieves a balance between "fine-grained retrieval" and "complete information tracing" through a parent-child document architecture. The core principle is that the parent document retains complete cases, while the child document supports precise retrieval. Strong associations are established through unique identifiers, ensuring that search results accurately match dimensional features while quickly retrieving complete information. The specific implementation is as follows: The core function of the parent document is as a "complete case container," and its structure consists of four parts: a unique identifier for the parent document, a list of associated child document IDs, complete case information, and associated metadata. Parent Document Unique Identifier (PID): The naming rule is consistent with the knowledge entry ID (e.g., KID20251105001), ensuring that the parent document corresponds one-to-one with the original knowledge entry, facilitating quick association; List of associated child document IDs: Lists all child document IDs associated with the current parent document in dimensional order (e.g., [DID-DS20251105001, DID-AS20251105001, DID-AR20251105001]), forming a direct mapping of parent-child relationships; Complete case information: Integrating all standardized fields of the original knowledge entry with the core content of each sub-document, retaining basic information such as ownership and registration date, while supplementing detailed descriptions in the sub-documents (such as data field details and algorithm process steps), forming a complete case with "basic information + detailed supplements"; Related metadata: includes the timestamp of the parent-child relationship establishment, the number of child documents, and the last update time, used to trace the creation and update records of the relationship.

[0037] Taking the parent document corresponding to knowledge entry KID20251105001 as an example, its complete content is: "Parent document ID: KID20251105001; List of associated child document IDs: [DID-DS20251105001, DID-AS20251105001, DID-AR20251105001]; Complete case information: Unique intellectual property identifier: 202510012345.6; Data name: E-commerce recommendation data based on user behavior; Data source: E-commerce platform user behavior logs; Data structure details: Structured data, containing 5 fields including user ID (string) and product ID (string), with a data scale of 5 million records." The storage format is Parquet; application scenario details: e-commerce industry, personalized product recommendation scenario on the platform, serving registered users, which can increase product exposure by 30%; algorithm rules details: adopts collaborative filtering + matrix factorization algorithm, recommendation accuracy of 85%, and achieves recommendation through user-product matrix construction, implicit semantic mapping, and similarity calculation; ownership: XX Technology Co., Ltd.; registration date: 2025-03-15; data security level: level 2 (medium-low risk); registration status: registered; associated metadata: association establishment time: 2025-11-05 14:20:33; number of sub-documents: 3; last update time: 2025-11-05 14:20:33.

[0038] The parent-child document relationship ensures reliability through a "two-way mapping": a "parent document ID" field is added to the child document (e.g., the parent document ID of DID-DS20251105001 is KID20251105001), and the parent document uses a "list of associated child document IDs" for reverse mapping, forming a closed-loop relationship. The encoding rules for unique identifiers ensure global uniqueness, and all IDs include a date field, facilitating the management of relationships by time. The generated parent-child document relationship system guarantees both the structured decomposition of knowledge and the traceability of complete information.

[0039] The knowledge entry vector set, sub-document set, and parent-child related document system are stored in the Chroma vector database to build a professional knowledge base with multi-dimensional retrieval capabilities.

[0040] This step is the physical implementation of the knowledge base. Its core is leveraging the efficient storage and retrieval capabilities of the Chroma vector database to integrate vector data, document data, and relationships, enabling multi-dimensional retrieval functions such as "vector similarity retrieval + dimensional filtering + parent-child relationship tracing." The specific implementation method is as follows: The Chroma vector database used is version 0.4.20. This version supports efficient storage of high-dimensional vectors, fast calculation of cosine similarity, and native metadata filtering, perfectly adapting to the multi-dimensional retrieval requirements of this method. The database is deployed in a local persistent mode, while a data backup mechanism is enabled (automatically backing up to cloud storage every morning) to ensure data security.

[0041] The storage structure is designed with three core collections, each corresponding to a different type of data: The knowledge entry vector collection (Collection name: knowledge_vector_collection) stores knowledge entry IDs, 1024-dimensional embedding vectors, and core metadata tags. These metadata tags include data type, application scenario, algorithm category, etc., and support tag filtering during retrieval. This collection is indexed using HNSW (HierarchicalNavigableSmallWorlds), with index parameters set to M=16 (adjacency list size) and ef_construction=200 (number of candidate nodes when building the index), ensuring a vector similarity retrieval response time ≤100ms (single query). Sub-document collection (Collection name: sub_document_collection): Stores sub-document ID, sub-document text content, parent document ID, dimension type, and sub-document embedding vector (also generated by the BGE-M3 model to achieve 512-dimensional vectors while maintaining retrieval efficiency). This collection simultaneously establishes vector indexes and text keyword indexes, supporting both "vector similarity retrieval" and "keyword retrieval" modes. The parent-child mapping collection (Collection name: parent_child_mapping_collection) stores the parent document ID, a list of associated child document IDs, and associated metadata. This collection establishes a bidirectional index between the parent document ID and the child document ID, supporting quick querying of all child documents by parent document ID, or quick tracing of the parent document by child document ID.

[0042] The implementation of multi-dimensional retrieval capabilities relies on Chroma's combined query function: during retrieval, matching sub-documents can be filtered out first through vector retrieval of the sub-document set (such as inputting the query vector of "e-commerce recommendation collaborative filtering") or keyword retrieval; then, through the parent-child association set, the corresponding parent document ID is obtained based on the sub-document ID; finally, the complete knowledge entry vector and metadata are obtained from the knowledge entry vector set through the parent document ID, forming a retrieval link of "sub-document matching → parent document tracing → complete information retrieval". For example, when a user queries "structured data based on collaborative filtering in the e-commerce field", the system first retrieves sub-documents related to "e-commerce field", "collaborative filtering", and "structured data" (such as DID-AS20251105001, DID-AR20251105001) in the sub-document set, associates the parent document ID of the sub-document with KID20251105001, and finally returns the complete case information and knowledge entry vector of the parent document.

[0043] The constructed professional knowledge base supports incremental updates and dynamic maintenance: when adding a new knowledge entry, a sub-document, a parent document, and the corresponding vector are generated simultaneously, inserted into the three sets respectively, and the association relationship is updated; when deleting or modifying a knowledge entry, the corresponding sub-document, vector, and associated record are deleted or updated in conjunction with a unique identifier, ensuring the consistency and accuracy of the knowledge base data.

[0044] S203, Generate a query vector based on the feature information of the data file to be processed, obtain a set of relevant cases from the professional knowledge base through vector similarity retrieval, and calculate the matching score between each case and the features of the input data; Specifically, it can parse the metadata and content structure of the data file to be processed, automatically extract field names, data type distribution, numerical range and data sample characteristics, and generate a data feature description document; This step is fundamental to obtaining the core features of the input data. The core is to comprehensively extract key features that characterize the essence of the data by parsing the file's metadata and content structure, providing a precise basis for subsequent query vector generation and case matching. The specific implementation method is as follows: The data file to be processed uses typical e-commerce user consumption behavior data as an example. The file format is CSV (comma-separated values), stored on the local file system, and the file name is "ecommerce_user_consumption_2025.csv". Metadata parsing is completed collaboratively with the data parsing library through the file system interface. The extracted metadata includes basic file attributes and structural attributes: the basic file attributes are "file size: 500MB; creation time: 2025-10-20 09:30:00; encoding format: UTF-8; number of rows: 1 million; number of fields: 4"; the structural attributes are "field separator: comma; whether there is a header: yes; percentage of missing values: 0.5%; percentage of duplicate records: 0.3%". This metadata intuitively reflects the overall situation of the file and provides preliminary information for subsequent content parsing.

[0045] The content structure analysis focuses on the core characteristics of the data, extracting them layer by layer according to the logic of "field-type-range-sample": Field names are obtained by parsing the file header, namely "user_id (unique user identifier), consume_date (consumption date), consume_amount (consumption amount), and product_category (product category)"; Data type distribution is determined by the format and semantics of field values: "user_id" is a string type (composed of letters and numbers, 10 characters long), "consume_date" is a date type (format "YYYY-MM-DD"), "consume_amount" is a numeric type (floating-point, rounded to two decimal places), and "product_category" is an enumeration type (value range: food, clothing, home appliances, cosmetics, digital products); The numeric range is calculated for the "consume_amount" field, and the minimum value of 10 is obtained by traversing 10% of the sample data (100,000 records). The data shows a maximum value of 4999.90 yuan, a mean of 800.25 yuan, a median of 650.70 yuan, and a standard deviation of 320.10 yuan, fully reflecting the numerical distribution characteristics. Three typical samples were selected for the data sample characteristics: Sample 1: user_id=U2025000001, consumption_date=2025-10-01, consumption_amount=399.90 yuan, product_category=clothing; Sample 2: user_id=U2025000002, consumption_date=2025-10-02, consumption_amount=1299.00 yuan, product_category=digital products; Sample 3: user_id=U2025000003, consumption_date=2025-10-03, consumption_amount=89.50 yuan, product_category=food.

[0046] The generated data feature description document is a structured text that integrates all the extracted information above. It is formatted correctly and contains complete information. An example is shown below: "Data Feature Description Document ID: DFD20251106001; Basic File Information: File Name: ecommerce_user_consumption_2025.csv, Format: CSV, Size: 500MB, Creation Time: 2025-10-2009:30:00, Number of Records: 1 million, Number of Fields: 4, Missing Values: 0.5%, Duplicate Records: 0.3%; Field Information: Field 1 (user_id) - String Type - Length: 10 characters - No Numerical Range - Sample U2025000001; Field 2 (consume_date) - Date" Period type - Format YYYY-MM-DD-No numerical range - Sample 2025-10-01; Field 3 (consume_amount) - Numeric (floating-point) - Range 10.50-4999.90 yuan - Mean 800.25 yuan - Median 650.70 yuan - Standard deviation 320.10 yuan - Sample 399.90 yuan; Field 4 (product_category) - Enumeration type - Values ​​[Food, Clothing, Home Appliances, Beauty, Digital] - Sample Clothing; Data application scenario prediction: E-commerce user consumption behavior analysis, user profile construction, product recommendation strategy optimization; Core data characteristics: Structured data, large scale (1 million records), contains numerical core fields of consumption amount, and enumeration fields related to multiple product categories.

[0047] Using the same BGE-M3 embedding model as the knowledge base, the data feature description document is converted into a query vector, generating a standardized query vector. This step transforms the textual feature descriptions into computer-computable vector forms. The core objective is to ensure that the query vectors are generated according to the same standards as the knowledge entry vectors in the knowledge base, thereby guaranteeing the accuracy of subsequent similarity retrieval. The specific implementation method is as follows: The BGE-M3 embedding model used in the knowledge base construction is adopted, and the model configuration is completely consistent: the large version checkpoint is selected, the vector output dimension is set to 1024 dimensions, the batch processing size is 1, the text truncation length is 512 characters, and the normalization parameter is set to True (mapping the vector values ​​to the [-1,1] interval), ensuring that the dimensions and distribution range of the query vector and the knowledge base vector are completely matched, avoiding similarity calculation deviations caused by differences in model parameters.

[0048] The model input is the complete data feature description document generated in step one. The input format is organized as a structured text string of "field name: field value" to ensure that the model can fully capture all key features. For example, the input text string is "Data file name: ecommerce_user_consumption_2025.csv; File format: CSV; Number of records: 1 million; Field information: user_id (string, sample U2025000001), consume_date (date type, sample 2025-10-01), consume_amount (numeric type, 10.50-4999.90 yuan, average 800.25 yuan), product_category (enumeration type, values ​​are food / clothing / home appliances / beauty / digital); Data type: structured data; Predicted application scenario: e-commerce user consumption behavior analysis; Missing value percentage: 0.5%".

[0049] The model processing procedure is as follows: First, the input text is segmented, part-of-speech tagging is performed, and semantic encoding is performed to map the professional terms in the text (such as "structured data", "e-commerce user consumption behavior", "numerical fields") into semantic vectors pre-trained by the model; then, deep semantic features are extracted through the multi-layer Transformer encoder of the model, integrating multi-dimensional information such as field type, data scale, and application scenario; finally, a 1024-dimensional vector is generated through the output layer, and the vector value is adjusted to the range of [-1,1] through L2 normalization to ensure that the vector magnitude is uniform, which is convenient for subsequent cosine similarity calculation.

[0050] The generated standardized query vector is a 1024-dimensional floating-point vector. Some vector values ​​are shown as: [0.0452, -0.0231, 0.0678, -0.0345, 0.0512, -0.0198, 0.0723, ..., -0.0089]. Dimensions with larger absolute values ​​in the vector correspond to the core features of the data. For example, the dimension value for "e-commerce" is 0.0723, for "structured data" it is 0.0678, and for "consumption amount" it is 0.0512. These high-response dimensions directly determine the matching direction of subsequent similarity retrieval, ensuring that the search accurately focuses on relevant cases.

[0051] Multi-level vector similarity retrieval is performed in the professional knowledge base. The sub-document vectors are retrieved using standardized query vectors, and the complete cases are obtained through parent-child association. The cosine similarity algorithm is used to calculate the similarity score and generate preliminary retrieval results. This step is the core retrieval process for achieving accurate case matching. Its core lies in a multi-layered retrieval logic of "sub-document vector matching → parent-child association tracing," ensuring both fine-grained accuracy and rapid retrieval of complete case information. The specific implementation is as follows: The core logic of multi-level vector similarity retrieval is "child first, parent later": the child document focuses on a single knowledge dimension (data structure, application scenario, algorithm rules) and can accurately match the specific features of the query vector, avoiding matching deviations caused by information redundancy in the complete case vector; after matching through the child document, the complete case is traced back by the parent-child relationship to ensure that the obtained case information is comprehensive and usable.

[0052] The retrieval process first performs vector similarity retrieval in the sub-document collection of the Chroma vector database, targeting sub-document vectors across all dimensions (data structure, application scenario, algorithm rules). The cosine similarity algorithm is used to calculate the similarity between the query vector and the sub-document vectors. The formula for cosine similarity is cosθ=(A・B) / (|A|×|B|), where A is the standardized query vector, B is the sub-document vector, A・B is the dot product of the two vectors, and |A| and |B| are the magnitudes of the two vectors, respectively. The similarity score ranges from [-1, 1]. A score closer to 1 indicates a stronger semantic relevance between the two vectors, while a score closer to -1 indicates a weaker relevance. A threshold of 0.5 is typically used to filter valid matching sub-documents.

[0053] For example, the dot product between the standardized query vector and a certain data structure sub-document (DID-DS20251015003, corresponding to the data structure description of "e-commerce user consumption data") is 0.892. The query vector magnitude is 1.0 (after normalization), and the sub-document vector magnitude is 1.0. The calculated cosine similarity is 0.892, which far exceeds the 0.5 threshold, and is therefore judged as a highly matched sub-document. The cosine similarity with a certain application scenario sub-document (DID-AS20251015003, corresponding to the scenario description of "e-commerce user behavior analysis") is 0.856, which is also a high match. The cosine similarity with a certain algorithm rule sub-document (DID-AR20251015003, corresponding to the description of "user consumption clustering algorithm based on K-means") is 0.783, which is still considered a valid match.

[0054] For each highly matched child document, its "parent document ID" field is used to associate it with the parent-child association collection (parent_child_mapping_collection) to obtain the corresponding parent document ID (e.g., PID20251015003). Then, based on the parent document ID, complete case information is extracted from the knowledge entry vector collection (knowledge_vector_collection), including data name, ownership, complete algorithm rules, core technical indicators, etc. The preliminary search results are organized in the structure of "sub-document matching score → parent document complete information". Each preliminary search result includes "parent document ID, list of associated sub-document IDs, similarity score of each sub-document, and complete case summary". For example: "Preliminary search result ID: PR20251106001; Parent document ID: PID20251015003; List of associated sub-document IDs: [DID-DS20251015003, DID-AS20251015003, DID-AR20251015003]; Sub-document similarity score: data structure 0.892, application scenario 0.856, algorithm rule 0.783; Complete case summary: Data name: e-commerce user consumption behavior clustering data; Data type: structured data; Data scale: 800,000 records; Application scenario: e-commerce user consumption behavior analysis and user segmentation; Core algorithm: K-means clustering algorithm; Core technical indicators: clustering purity 88%, running time ≤10 minutes; Ownership: XX Data Technology Co., Ltd."

[0055] The generated preliminary search results include the top 15 complete cases sorted in descending order of average similarity score of sub-documents. The average similarity score is calculated as (data structure similarity + application scenario similarity + algorithm rule similarity) / 3. For example, the average similarity score of the above case is (0.892 + 0.856 + 0.783) / 3 ≈ 0.844, ranking second in the preliminary search results, ensuring that the preliminary search results can cover the most relevant core cases.

[0056] A comprehensive matching analysis is performed on the preliminary search results. The final matching score for each case is calculated by combining feature overlap and semantic similarity. The relevant cases are then sorted in descending order of the scores to generate a set of related cases.

[0057] This step involves refining the initial search results. The core of this process is to eliminate the limitations of a single similarity metric through multi-dimensional comprehensive scoring, ensuring that the final set of relevant cases highly matches the characteristics of the input data. The specific implementation method is as follows: The comprehensive matching analysis adopts a weighted scoring model of "feature overlap × 0.4 + semantic similarity × 0.6". Feature overlap focuses on the objective structural feature matching of the data, while semantic similarity focuses on the subjective semantic association. The weight allocation is based on the degree of influence of the two on case matching (semantic similarity is more critical for the matching of application scenarios and algorithm logic, so it has a higher weight).

[0058] The calculation logic for feature overlap is to statistically compare the overlap ratio between input data and case data on core objective features. Core objective features include five dimensions: data type, number of fields, core field type, data scale, and application scenario category. Each dimension scores 20 points for a match, for a total of 100 points. Feature overlap = (actual matching dimension score / 100). For example, the feature overlap between the input data and the above case is as follows: data type (structured data) match (20 points), number of fields (4 in the input / 4 in the case) match (20 points), core field type (numerical core field `consume_amount` / case numerical core field `consume_value`) match (20 points), data scale (1 million in the input / 800,000 in the case, both "million-level") match (20 points), application scenario category (e-commerce user consumption behavior analysis) match (20 points). The actual matching dimension score is 100 points, and the feature overlap = 100 / 100 = 1.0.

[0059] Semantic similarity is achieved by using the average similarity score of sub-documents in the preliminary search results. For example, the average similarity score in the above case is 0.844, which is directly used as the semantic similarity indicator.

[0060] The final matching score is calculated as follows: Final score = (feature overlap × 0.4 + semantic similarity × 0.6) × 100. Substituting the above case data, we get: Final score = (1.0 × 0.4 + 0.844 × 0.6) × 100 = 90.64 points. The score result is rounded to two decimal places, which directly reflects the degree of matching between the case and the input data.

[0061] The above calculations were performed on each of the 15 cases in the preliminary search results. The cases were then sorted in descending order of their final matching scores, and the top 10 cases were selected to generate a related case set. The structured format of the related case set is "Case Ranking Number, Parent Document ID, Final Matching Score, Core Feature Matching Points, Full Case Access Link", for example: "Related Case Set ID: RCS20251106001; Ranking 1: Parent Document ID PID20251020005, Final Score 92.35, Core Matching Points: Data Type / Number of Fields / Core Fields / Data Scale / Application Scenarios Full Match, Semantic Similarity 0.872; Ranking 2: Parent Document ID PID20251015" 003, final score 90.64, core matching points: full match in data type / number of fields / core fields / data scale / application scenario, semantic similarity 0.844; Rank 3: Parent document ID PID20251018007, final score 85.72, core matching points: match in 4 dimensions, semantic similarity 0.831; ... Rank 10: Parent document ID PID20251009012, final score 75.18, core matching points: match in 3 dimensions, semantic similarity 0.765. This set ensures both the accuracy of the matching and provides a sufficient number of cases for subsequent multi-dimensional integration, offering rich reference for the generation of application materials.

[0062] S204, the relevant case set and input data features are fused in multiple dimensions, and the large language model is guided to generate data intellectual property application materials containing algorithm rule descriptions and executable code through preset multi-round prompt templates; Specifically, context alignment analysis can be performed between relevant case sets and input data features to identify key feature matching points and differences, and generate enhanced contextual information; This step is a core prerequisite for multi-dimensional fusion. Its core is to accurately align the feature dimensions of the input data with those of the reference cases, clarifying their commonalities and differences. This provides a "targeted" reference for the large model, preventing the generated content from deviating from the actual input data. The specific implementation method is as follows: Context alignment analysis employs a dual-track logic of "dimensional mapping + semantic comparison." Dimensional mapping focuses on objective structural features, while semantic comparison focuses on subjective application and technical features, covering five core dimensions: data type, data scale, core fields, application scenarios, and algorithm requirements. Taking the input data (e-commerce user consumption behavior data: structured, 1 million records, including the `consume_amount` numeric field, used for consumption behavior analysis) and the top 3 cases in the relevant case set as examples, alignment analysis is conducted one by one: Case 1 (PID20251020005, final score 92.35): Data type is structured, data scale is 900,000 records, core field includes "consumption amount (numerical)," application scenario is "e-commerce user segmentation," and algorithm is "K-means clustering." Key feature matching points: Data type, core field (consumption amount), application scenario (e-commerce), and data scale (millions) are completely consistent; Differences: The input data needs to achieve a dual objective of "consumption behavior trend analysis + user segmentation," but this case only focuses on user segmentation, and the algorithm needs to supplement with a trend statistics module.

[0063] Case 2 (PID20251015003, final score 90.64): Data type is structured, data scale is 800,000 records, core field includes "Consumption Amount (numerical)", application scenario is "consumer behavior analysis", algorithm is "K-means clustering + time series statistics". Key feature matching points: all core dimensions are highly matched, the algorithm has covered the dual objectives of the input data; Differences: the input data includes a "product category" enumeration field, the case does not involve correlation analysis of this field, and "Consumption Amount - Product Category" cross statistics need to be added.

[0064] Case 3 (PID20251018007, final score 85.72): Data type is structured, data scale is 500,000 records, core field includes "transaction amount (numerical)," application scenario is "user consumption preference mining," and algorithm is "collaborative filtering recommendation." Key feature matching points: Data type and core field semantics (transaction amount ≈ consumption amount) are consistent; Differences: Data scale is different (500,000 records vs. 1 million records), application scenario focuses on preference mining rather than trend + stratification, and algorithm types are mismatched (recommendation vs. clustering + statistics).

[0065] The generated enhanced context information integrates all alignment results and is presented in a structured format of "core features of input data + case matching summary + matching point summary + difference point supplementary requirements", as shown in the following example: "Enhanced Context Information ID: ECI20251107001; Core features of input data: structured data, 1 million records, including user_id (string), consume_date (date), consume_amount (numerical, 10.50-4999.90 yuan), product_category (enumerated type), target application is e-commerce user consumption behavior trend analysis + user segmentation; Case matching summary: Top 2 cases (PID20251020005, The PID (20251015003) is highly matched to the input data, with identical core fields and application domains. The algorithm can reuse the K-means clustering module. Key matching points: data type (structured), core field (consumption amount), application scenario (e-commerce), data scale (millions of records), and algorithm foundation (clustering). Differences requiring supplementation include: 1. Integrating K-means clustering (user stratification) and time series statistics (trend analysis); 2. Adding cross-analysis for product_category and consumption_amount; 3. Optimizing algorithm efficiency for 1 million data entries (maximum case size 900,000 records); 4. Supplementing missing value handling logic (input data missing values ​​account for 0.5%). This information highlights reusable case resources and clarifies the specific content requiring supplementation, providing precise guidance for large-scale models.

[0066] Following a pre-defined multi-round prompt template sequence, the system sequentially loads prompts such as system role definitions, task specification descriptions, output format requirements, and algorithm design guidelines to generate a structured prompt sequence. This step is crucial for guiding the large model to accurately generate content. Its core is to use standardized, structured prompt templates to clearly define the large model's role, task boundaries, output format, and technical requirements, thus avoiding generated content that is disorganized, logically flawed, or does not comply with intellectual property application regulations. The specific implementation method is as follows: The pre-designed multi-round prompt template sequence is arranged according to a progressive logic of "role-standard-format-guideline", with a total of 4 rounds of prompts. Each round of prompts focuses on a single core objective, and the content has been calibrated according to the intellectual property application material standards to ensure that the generated results meet the registration requirements. Round 1: System Role Definition Template. The overall model's role is clearly defined as "Data Intellectual Property Application Material Generation Expert," with the core responsibility of "generating application materials that comply with intellectual property registration standards, are logically rigorous, and have complete technical details, based on input data characteristics and reference cases." The constraints include: "Strictly adhere to the actual characteristics of the input data, do not fabricate non-existent fields or algorithms, and the technical description must be professional and implementable." Example prompt: "You are a Data Intellectual Property Application Material Generation Expert. You are required to generate application materials that comply with national intellectual property registration standards based on the provided e-commerce user consumption behavior data characteristics and relevant reference cases. Requirements: Generate content only based on real input characteristics, do not fabricate fields, data, or algorithms; the technical description must be professional and accurate, and the algorithm rules must be implementable; the language must be formal and standardized, avoiding colloquial expressions."

[0067] Round Two: Task Specification Template. This section clarifies the core task and required content of the application materials. The core task is to "generate complete application materials including basic data information, application scenario description, detailed algorithm rules, and technical indicator descriptions." Required content includes seven modules: data name, data source, data structure, application scenario, algorithm flow, core technical indicators, and explanation of innovation. It also emphasizes that "innovation must combine cross-analysis of input data and integration of dual-objective algorithms." Example prompt: "This task requires generating data intellectual property application materials. Required modules include: 1. Data name (must reflect core characteristics); 2. Data source (clearly state collection channels and compliance); 3. Data structure (field names, types, constraints); 4. Application scenario (specific implementation scenarios and value); 5. Algorithm rules (complete process and core steps); 6. Core technical indicators (quantify algorithm performance); 7. Explanation of innovation (highlighting the differences from reference cases). Innovation should focus on two main directions: 'cross-analysis of consumption amount and product category' and 'integration of clustering + trend statistics for dual objectives.'"

[0068] Round Three: Output Format Requirements Template. The application materials should be presented in a structured format, using a "chapter-based + item-based" approach. Each module should be organized as "first-level heading + second-level subheading + main text." The algorithm rules section must be described step-by-step, and technical indicators must clearly state their numerical values ​​and calculation methods. Additionally, the algorithm code must be a separate section, written in Python, and clearly commented. Example prompts: "Output format requirements: 1. The overall structure should be chapter-based, with first-level headings labeled 'I, II, III' and second-level subheadings labeled '(I), (II), (III)'; 2. The data structure module must list the names, types, and value ranges of all fields; 3. The algorithm rules module must be described step-by-step according to 'data preprocessing → core algorithm → result output,' with each step including specific logic; 4. Core technical indicators must be quantified (e.g., cluster purity ≥ 85%), and the calculation method explained; 5. The algorithm code should be listed separately as 'VI. Executable Data Processing Code,' and the code must be complete and runnable, including data reading, preprocessing, algorithm implementation, and result evaluation modules, with comments added to key steps."

[0069] Round Four: Algorithm Design Guidelines Template. Based on the supplementary requirements for differences in enhanced contextual information, this section provides specific directions for algorithm design, including data preprocessing strategies (missing value handling, outlier filtering), core algorithm selection (K-means clustering parameter settings, time series statistical methods), and efficiency optimization schemes (batch processing, parallel computing). Example prompts: "Algorithm Design Guidelines: 1. Data Preprocessing: Fill missing values ​​(consume_amount field) with the mean, and filter outliers using the 3σ criterion; 2. K-means Clustering: Set the number of clusters to 5 (corresponding to high, medium-high, medium, medium-low, and low consumption levels), with ≥100 iterations, and use Euclidean distance for similarity calculation; 3. Time Series Statistics: Group by month according to the consumption_date field, and calculate the monthly consumption amount mean, median, and growth rate; 4. Cross-analysis: Statistically analyze the consumption amount percentage and user distribution of each product_category; 5. Efficiency Optimization: Use MiniBatchKMeans to adapt to 1 million data points, with a batch size of 1000."

[0070] The generated structured prompt sequence is assembled in the order of the above four rounds of prompts to form a complete guiding text with a total length of about 800 words. It clarifies "what to do, how to do it, and what to make it look like", and provides specific technical design references for the large model, ensuring that the generated content is both compliant and accurate.

[0071] The enhanced contextual information and structured prompt sequences are input into the large language model, and a draft of the application materials containing data names, source descriptions, application scenarios, and algorithm rule descriptions is generated through a chain reasoning mechanism. This step is the core execution stage of application material generation. Its core lies in leveraging the chain-reasoning capabilities of a large model, progressing step-by-step from "understanding the needs → reusing cases → supplementing innovation → organizing content" to generate a logically complete and detailed initial draft of the application materials. The specific implementation method is as follows: The GPT-4 model was selected to perform the generation task. This model possesses powerful logical reasoning and professional text generation capabilities, accurately understands the requirements of structured prompt sequences, and performs chain reasoning by combining enhanced contextual information. Step 1 Reasoning (Determining the Core Positioning): Based on the characteristics of the input data and the prompt requirements, the data name is determined to be "Multi-dimensional Analysis Data of E-commerce User Consumption Behavior", which reflects both the core field (consumption behavior) and the application goal (multi-dimensional analysis); the data source is clearly defined as "consumption logs of registered users on e-commerce platforms collected in compliance with regulations, authorized by users and anonymized, in accordance with the requirements of the Personal Information Protection Law", ensuring a complete description of compliance.

[0072] The second step of reasoning (reusing basic case information): Reuse the structured description framework of Case 1 and Case 2, supplement the specific information of the input data, and generate the data structure module: "(I) Data structure: 1. Field name: user_id, field type: string, value range: 10-digit alphanumeric combination, constraint: not empty, unique; 2. Field name: consume_date, field type: date, format: YYYY-MM-DD, constraint: not empty; 3. Field name: consume_amount, field type: floating point, value range: 10.50-4999.90 yuan, constraint: ≥0; 4. Field name: product_category, field type: enumeration, value range: food, clothing, home appliances, beauty, digital products, constraint: not empty".

[0073] The third step of reasoning (supplementing innovative application scenarios): Combining the dual-objective requirements of the input data, generate application scenario descriptions: "(II) Application Scenarios: 1. E-commerce user segmentation operation: Based on the clustering results of consumption amount, provide VIP services for high-spending users and push coupons to low- and medium-spending users to improve conversion efficiency; 2. Consumption trend prediction: Through monthly consumption amount statistics and growth rate analysis, predict the hot-selling product categories and guide the platform's inventory scheduling; 3. Category association recommendation: Based on the cross-analysis of product_category and consumption_amount, mine association rules such as 'high-spending users prefer digital products' and optimize the recommendation strategy. Application value: It can increase the platform's user repurchase rate by 15% and the inventory turnover rate by 20%."

[0074] Step 4 Reasoning (Designing Complete Algorithm Rules): Integrate case algorithm and supplementary requirements for differences to generate algorithm rule descriptions: "(III) Algorithm Rules: 1. Data Preprocessing: a. Missing Value Handling: Missing values ​​in the consume_amount field are filled with the mean of the product category; b. Outlier Filtering: Outlier records in the consume_amount field exceeding [10.50, 4999.90] are removed using the 3σ criterion; c. Data Standardization: The consume_amount field is mapped to the [0,1] interval to avoid the magnitude affecting the clustering results. 2. Core Algorithm: aK-m" EANS clustering: Input the standardized `consume_amount` field, set the number of clusters to 5, iterate 100 times, calculate similarity using Euclidean distance, and output user consumption level labels; b. Time series statistics: Group by `consume_date` by month, calculate the monthly average, median, and month-on-month growth rate of consumption amount; c. Cross-analysis: Statistically analyze the consumption amount percentage and user number percentage of each `product_category`, and generate a category-consumption level association matrix. 3. Output results: Output three main results: a user segmentation result table, a monthly consumption trend chart, and a category association rule table.

[0075] Step 5 Reasoning (Quantifying Core Technical Indicators): Combining case indicators with input data to optimize the target, generate technical indicators: "(IV) Core Technical Indicators: 1. Cluster purity: ≥88% (calculation method: the average of the number of consumer level samples with the highest proportion in each cluster / the total number of samples in the cluster); 2. Algorithm running time: ≤15 minutes (based on 1 million data points, single-threaded operation); 3. Trend analysis accuracy: ≥90% (compared with actual sales data); 4. Outlier filtering accuracy: ≥95% (verified by manual annotation)."

[0076] The generated draft application materials fully cover all seven modules required by the prompt sequence. They are logically coherent and rich in detail. They not only reuse the structured framework of the case but also specifically supplement the innovative and different points of the input data, laying the foundation for subsequent code conversion.

[0077] The initial draft of the application materials is converted into algorithm code, and executable Python data processing code is automatically generated based on the algorithm rule description, ultimately generating complete data intellectual property application materials.

[0078] This step is a practical supplement to the application materials. Its core is to transform the abstract algorithmic rules into executable code, verify the algorithm's feasibility, and simultaneously meet the "technical feasibility" requirement for intellectual property applications. The specific implementation method is as follows: The algorithm code conversion follows the principle of "rule-by-rule mapping + engineering optimization," strictly adhering to the algorithm steps in the initial draft while supplementing engineering details (such as data reading, result saving, and exception handling) to ensure the code is directly executable. The code is written in Python (a mainstream language for data processing with strong compatibility), and the dependent libraries are pandas (data processing), scikit-learn (clustering algorithm), and numpy (numerical computation), with versions adapted to pandas 1.5.3, scikit-learn 1.2.2, and numpy 1.24.3 to ensure environment compatibility.

[0079] Based on the algorithm rules in the initial draft, the code is implemented in modules: Data reading and preprocessing module: Implements CSV file reading, missing value mean filling, 3σ outlier filtering, and data standardization according to the initial draft requirements. For example, it reads the "ecommerce_user_consumption_2025.csv" file, calculates the mean of consumption_amount using groupby(product_category) to fill missing values, calculates the mean of consumption_amount to remove outliers by calculating the mean μ=800.25 and the standard deviation σ=320.10, removes outliers exceeding [μ-3σ,μ+3σ], and maps consumption_amount to the [0,1] interval using MinMaxScaler.

[0080] Core algorithm module: Implements K-means clustering (using MiniBatchKMeans to adapt to 1 million data points), time series statistics, and cross-analysis. For example: initialize the clustering model with n_clusters=5, max_iter=100, and batch_size=1000, and output user level labels after fitting the data; group by "year-month" of consumption_date and calculate mean, median, and pct_change (month-on-month growth rate); calculate the correlation matrix between product_category and consumption level through crosstab and calculate the proportion.

[0081] Results Output and Evaluation Module: Saves user stratification results table (CSV format), monthly trend chart (PNG format), category association rule table (CSV format), calculates cluster purity and prints evaluation results. For example, it calculates the maximum sample proportion of each cluster through the confusion matrix, takes the average value to obtain the cluster purity, and prints "Cluster purity: 89.2%" and "Algorithm running time: 12.3 minutes".

[0082] Detailed comments were added to key steps in the code, such as: "# Fill missing values ​​by product category to ensure consistent data distribution within the same category" and "# Use MiniBatchKMeans to improve the efficiency of large-scale data processing, batch size 1000". The generated code is complete, runnable, and free of syntax errors, accurately reproducing the algorithm logic in the initial draft.

[0083] The final generated complete data intellectual property application materials integrate "initial draft of application materials + executable Python code", organized in a chapter-based structure according to the prompt sequence requirements, including: "I. Data Name and Core Positioning", "II. Data Source and Compliance Explanation", "III. Data Structure Details", "IV. Application Scenarios and Commercial Value", "V. Algorithm Rules and Technical Indicators", "VI. Executable Data Processing Code", and "VII. Innovative Explanation" (7 chapters). The format is standardized, the logic is rigorous, and the technical details are complete, which not only meets the compliance requirements of intellectual property registration, but also has strong feasibility.

[0084] S205 involves automatically verifying the generated application materials and executing the data processing algorithms within them. After ensuring the correct operation of the code through a self-healing execution mechanism, a structured registration application is submitted to the intellectual property platform.

[0085] Specifically, the generated application materials can be checked for format compliance, the completeness and format specifications of required fields can be verified, and a material verification report can be generated. This step is a basic verification process before submitting application materials. Its core purpose is to ensure that the materials meet the format requirements for intellectual property registration, avoiding rejection due to missing fields or format errors, and clearing obstacles for subsequent submissions. The specific implementation method is as follows: The format compliance check revolves around two core aspects: "completeness of required fields" and "format standardization." Based on the national data intellectual property registration and management regulations, 12 required fields are specified in the application materials: [Data Name], [Data Source], [Data Type], [Data Structure], [Data Scale], [Ownership of Rights], [Application Scenarios], [Algorithm Rule Description], [Core Technical Indicators], [Innovation Description], [Executable Code], and [Compliance Declaration]. Each field has clearly defined format requirements and filling specifications.

[0086] The completeness check for required fields employs a "field traversal + semantic validation" approach: First, all sections of the application materials are traversed, and each of the 12 required fields is checked for missing values, empty values, or overly brief descriptions. If a field description does not meet the specifications (e.g., the "Core Technical Indicators" section only states "high cluster purity" without quantifying the value), it is deemed "incomplete." For example, in an application for e-commerce user consumption behavior data, the "Compliance Declaration" field only states "complies with relevant regulations" without explicitly mentioning specific legal grounds such as the "Personal Information Protection Law" or the "Data Security Law," thus it is deemed incomplete; the "Data Scale" field explicitly states "1 million records," meeting the completeness requirements.

[0087] Format compliance checks have specific validation rules for different types of fields: Text fields (such as [Data Name], [Application Scenario]) require formal language, avoiding colloquial expressions, and a character length of 20-500 characters; Numerical fields (such as [Core Technical Indicators]) require quantitative descriptions, including specific values ​​and calculation methods (e.g., "Cluster purity: 89.2%, calculated as the average of the number of consumer level samples with the highest proportion in each cluster / the total number of samples in that cluster"); Date fields (such as [Data Collection Time]) require a uniform format of "YYYY-MM-DD"; Code fields (such as [Executable Code]) require correct syntax, clear comments, and no redundant or invalid code; Compliance declaration fields require explicit citation of at least two relevant laws and regulations, explaining the compliance basis for data collection and use.

[0088] The generated material verification report is a structured document containing four parts: "Verification Overview, List of Qualified Fields, List of Problematic Fields, and Rectification Suggestions." The Verification Overview clearly states the verification time, material ID, and verification result (qualified / unqualified), for example, "Verification Time: 2025-11-08 15:30:00; Material ID: IP20251108001; Verification Result: Unqualified (2 fields incomplete, 1 field format error)." The List of Qualified Fields lists all compliant fields with brief descriptions. The List of Problematic Fields details the problem type and specific problem description, for example, "Problem Field 1: [Compliance Statement] - Incomplete field - No clear reference to specific laws and regulations; Problem Field 2: [Core Technical Indicators] - Format error - 'Short running time' not specified." Quantified numerical values; Problem field 3: [Innovation Description] - Incomplete field - Failure to highlight the innovative differences from existing cases; Rectification suggestions provide specific directions for correction for each problem, such as "Suggestion 1: [Compliance Statement] Add 'This data collection and use complies with Article xx of the Personal Information Protection Law or the Data Security Law, and has obtained user authorization and completed de-identification processing'; Suggestion 2: [Core Technical Indicators] Revise 'Short running time' to 'Algorithm running time: 12.3 minutes (based on 1 million data points, single-threaded operation)'; Suggestion 3: [Innovation Description] Add 'Compared to existing cases, this application adds a cross-analysis module for product categories and consumption amounts, achieving the integration of consumption trends and user segmentation as dual objectives, and optimizing efficiency for large-scale data of 1 million data points'."

[0089] Run the data processing algorithms in the application materials in an isolated code execution environment, monitor the execution process in real time and capture runtime exceptions to generate code execution results; This step is the core of verifying the algorithm's feasibility. By isolating the environment, it prevents the code from affecting the system, while accurately capturing runtime exceptions to provide a basis for subsequent self-healing repairs. The specific implementation method is as follows: The isolated code execution environment is deployed using Docker containers, creating an independent Python runtime environment completely isolated from the host system. This prevents malicious instructions or resource consumption in the code from affecting the normal operation of the host. The environment configuration strictly matches the code dependency requirements: Python version 3.9.16 (the compatible version used during code development), pre-installed libraries such as pandas 1.5.3, scikit-learn 1.2.2, numpy 1.24.3, and matplotlib 3.7.1, resource limits are 4 CPU cores, 8GB of memory, and 20GB of disk space, with a runtime timeout threshold set to 30 minutes (to allow sufficient runtime for processing 1 million data entries).

[0090] The code execution process adopts a "step-by-step execution + real-time monitoring" mode: First, the executable code is split into functional modules (data reading, preprocessing, core algorithm, result output), and each module is executed in sequence while the running status is recorded; the core indicators for real-time monitoring include CPU utilization, memory usage, disk I / O, and runtime, with a monitoring frequency of 1 time / second. If a certain indicator exceeds the threshold (CPU utilization ≥ 90%, memory usage ≥ 80%, runtime ≥ 30 minutes), the interrupt mechanism is automatically triggered, and the abnormal status is recorded.

[0091] Runtime exception handling employs a dual mechanism of "syntax parsing + exception interception": Before code execution, the Python syntax parser verifies the syntax correctness. If a syntax error is found (such as a missing colon, indentation error, or undefined variable), execution is terminated directly and a syntax error log is recorded. During code execution, common runtime exceptions are intercepted using try-except statements, including ImportError (missing dependency), FileNotFoundError (incorrect file path), MemoryError (out of memory), and ValueError (incorrect value). Each time an exception is caught, the exception type, error location, error description, and context information are immediately recorded.

[0092] For example, in the executable code of an application material, the MinMaxScaler class was used directly without being imported, triggering an ImportError exception during execution. The error log records: "Exception type: ImportError; Error location: line 23 of the code; Error description: name 'MinMaxScaler' is not defined; Context information: line 23 of the code attempts to initialize a MinMaxScaler object for data standardization, but the MinMaxScaler class in sklearn.preprocessing is not imported." If the code processes 1 million data points, a memory overflow occurs due to the batch size being set too small, triggering a MemoryError exception. The error log records: "Exception type: MemoryError; Error location: line 45 of the code; Error description: Unable to allocate 8.0 GiB for an array with shape (1000000, 10) and data type float 64; Context information: the batch size of the K-means clustering module is set to 500, and the large amount of data causes insufficient memory."

[0093] The generated code execution results include four parts: "execution status, runtime metrics, exception log, and result file list". The execution status is divided into "success / failure / timeout", for example, "execution status: failure; exception triggered: ImportError + MemoryError". The runtime metrics record the actual runtime and peak resource usage of each module, for example, "data reading module: runtime 0.5 minutes, peak memory usage 1.2GB; preprocessing module: runtime 3.2 minutes, peak memory usage 2.5GB; core algorithm module: runtime 5.1 minutes, peak memory usage 7.8GB (triggered memory overflow)". The exception log lists all captured exception information in detail. The result file list records the successfully generated intermediate or final results (such as CSV files after data preprocessing). If the execution fails, it is marked "no valid result file".

[0094] When a code execution error is detected, a self-healing execution mechanism is activated. The error log is analyzed using a large language model to generate a repair plan. The code is automatically corrected and then re-executed to generate corrected executable code. This step is a crucial fix to ensure the algorithm's viability. Its core is leveraging the error analysis and code repair capabilities of a large language model to automatically resolve runtime anomalies, avoiding manual intervention and improving the feasibility of application materials. The specific implementation method is as follows: The self-healing execution mechanism is triggered when there is a "syntax error", "runtime exception" or "timeout" in the code execution result. After it is started, it automatically proceeds according to the process of "error analysis → repair solution generation → code correction → re-execution". Its core relies on the code understanding and generation capabilities of the GPT-4 model.

[0095] Error Analysis Phase: The exception logs from code execution, the complete code, and the algorithm rule descriptions from the application materials are all input into the large language model. The model uses semantic parsing to clarify the nature and root cause of the errors. For example, for the ImportError exception, the model analysis concludes that "the root cause is the missing import statement for the MinMaxScaler class, which is a syntax omission error"; for the MemoryError exception, the model, combining the algorithm rule description and the data scale (1 million records), analyzes that "the root cause is that the batch size for K-means clustering is set too small (500), resulting in excessive memory usage, which is an unreasonable parameter configuration error"; for the FileNotFoundError exception, the model analysis concludes that "the root cause is an incorrect data file path; the data file storage path in the application materials is ' / data / ecommerce.csv', but in the code it is written as ' / data / user.csv', which is a path spelling error."

[0096] Repair solution generation stage: Based on the error analysis results, the large language model combines the algorithm logic and data characteristics of the application materials to generate specific and executable repair solutions, including explanations of the error causes, repair steps, and corrected code snippets.

[0097] Code correction phase: The self-healing execution mechanism automatically replaces the erroneous parts of the original code with corrected code snippets generated by the large language model. Simultaneously, it performs syntax verification on the corrected complete code to ensure there are no new syntax errors. For example, after replacing import statements, adjusting the batch_size parameter, and correcting file paths, a Python syntax parser quickly verifies the code to confirm its grammatical correctness.

[0098] Re-execution phase: The corrected code is resubmitted to the isolated execution environment, and the running and monitoring process in step two is repeated. If errors are still detected, the self-healing execution mechanism is restarted, iterating and repairing until the code runs successfully (maximum of 3 iterations to avoid infinite loops). For example, after the first repair, ImportError and path errors were resolved, but memory overflow still existed. After the model was re-analyzed, the batch_size was adjusted to 8000. After the second re-execution, the code ran successfully without any exceptions.

[0099] The generated corrected executable code contains complete functional modules, clear comments, and can accurately reproduce the algorithm logic in the application materials. For example, the corrected code starts with complete import statements, the parameters of the core algorithm module are configured reasonably, the data reading path is correct, and comments are added to key steps to explain the repair logic, ensuring that the code can be run directly and the results meet expectations.

[0100] The verified application materials and successfully executed data processing algorithms are packaged into a structured data package, and the registration application is automatically submitted through the intellectual property platform API interface, generating a submission confirmation receipt.

[0101] This step is the final execution stage of the application process. Its core is to package the data according to the platform's requirements and submit it via the API interface, ensuring that the application materials are securely and accurately delivered to the intellectual property registration system. The specific implementation method is as follows: The structured data packets are packaged according to the file format requirements of the intellectual property platform, using ZIP compression format with a compression level of 6 (balancing compression efficiency and file size). The data packet naming rule is "Data Intellectual Property Application_Material ID_Submission Date.zip", for example, "Data Intellectual Property Application_IP20251108001_20251108.zip". Internally, the data packets are stored in categories of "documents + code + results": Documents include application materials that have passed format verification (PDF format, named "Application Materials.pdf") and material verification reports (PDF format, named "Material Verification Report.pdf"); Code includes the corrected executable code (.py format, named "Data Processing Algorithm.py") and code execution result reports (TXT format, named "Code Execution Result.txt"); Results include intermediate and final result files generated by the code execution (CSV format user segmentation results and PNG format trend charts, named "User Segmentation Results.csv" and "Monthly Consumption Trend Chart.png" respectively). After packaging, the data packet is calculated using the MD5 algorithm. This is used by the platform to verify the integrity of the data when it receives it. For example, the MD5 checksum is "7a3f9d2e8b4c10576890a1b2c3d4e5f6".

[0102] The API submission process requires prior platform authentication and parameter configuration: First, register an account on the intellectual property platform and complete enterprise real-name authentication to obtain API access keys (AccessKeyID and AccessKeySecret) for authentication of interface requests. The API address is the "Data Intellectual Property Registration Application Submission Interface" provided by the platform, with the request method being POST. The request header includes Content-Type (application / json), Authorization (signature generated based on AccessKey), and Timestamp (request timestamp, accurate to milliseconds). The request parameters include three parts: "Applicant Information, Data Package Information, and Verification Information." The applicant information includes the enterprise name, unified social credit code, contact person, and contact information; the data package information includes the data package name, MD5 checksum, and Base64 encoding of the data package (direct encoding transmission is supported because the data package size is ≤200MB); and the verification information includes the application material ID and submission timestamp.

[0103] During the submission process, the system automatically completes identity verification and data integrity checks: The platform verifies the applicant's identity through the signature in the Authorization header; if the signature is incorrect, it returns "401 Unauthorized"; it verifies the integrity of the data packet by comparing the MD5 checksum; if the checksums do not match, it returns "400 Bad Request" with the message "Data packet corrupted, please resubmit"; if the identity is valid and the data is complete, the platform receives the data packet and returns "200 OK", indicating successful submission.

[0104] The generated submission confirmation receipt is a JSON document containing core information such as "application number, submission time, acceptance status, estimated review time, and query link," for example, "{"application number":"IPR202511080001","submission time":"2025-11-08 16:45:30","acceptance status":"accepted","estimated review time":"30 working days","query link":"xxxxx","remarks":"Please track the review progress through the query link. The review result will be notified to the contact person via SMS"}). The receipt is automatically stored locally in a specified path and simultaneously sent to the applicant's pre-registered email address and mobile phone number, ensuring that the applicant can monitor the submission status in real time. This receipt is an important basis for subsequent inquiries about the review progress and receipt of the registration certificate, marking the completion of the entire data intellectual property structure generation and submission process.

[0105] Another embodiment of the present invention provides a data intellectual property structure generation system based on large-model cognitive intelligence discovery, see [link to relevant documentation]. Figure 3 The system may include: The extraction module 301 is used to extract registered data intellectual property information from multiple data sources through the data acquisition layer, and to perform structured processing on the information based on a predefined template to generate standardized knowledge entries; The conversion module 302 is used to convert the standardized knowledge items into high-dimensional vector representations using an embedding model, and to construct a professional knowledge base with a parent-child document association architecture, wherein the child documents focus on specific knowledge dimensions while the parent documents maintain complete case information; The acquisition module 303 is used to generate a query vector based on the feature information of the data file to be processed, obtain a set of relevant cases from the professional knowledge base through vector similarity retrieval, and calculate the matching degree score between each case and the input data features; The generation module 304 is used to fuse the relevant case set with the input data features in multiple dimensions, and guide the large language model to generate data intellectual property application materials containing algorithm rule descriptions and executable code through preset multi-round prompt templates; The execution module 305 is used to automatically verify the generated application materials and execute the data processing algorithms therein. After ensuring that the code runs correctly through a self-healing execution mechanism, it submits the structured registration application to the intellectual property platform.

[0106] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0107] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0108] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0109] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for generating structured data intellectual property based on large-scale model cognitive intelligence discovery, characterized in that, The method includes: The data acquisition layer extracts registered intellectual property information from multiple data sources and performs structured processing on the information based on predefined templates to generate standardized knowledge entries. The standardized knowledge items are converted into high-dimensional vector representations using an embedding model, and a professional knowledge base with a parent-child document association architecture is constructed, wherein the child documents focus on specific knowledge dimensions while the parent documents maintain complete case information; A query vector is generated based on the feature information of the data file to be processed. A set of relevant cases is obtained from the professional knowledge base through vector similarity retrieval, and the matching degree score between each case and the features of the input data is calculated. The relevant case set is fused with the input data features in multiple dimensions, and the large language model is guided to generate data intellectual property application materials containing algorithm rule descriptions and executable code through preset multi-round prompt templates. The generated application materials are automatically verified and the data processing algorithms are executed. After ensuring the correct operation of the code through a self-healing execution mechanism, a structured registration application is submitted to the intellectual property platform.

2. The method according to claim 1, characterized in that, The process of extracting registered intellectual property information from multiple data sources through a data acquisition layer and generating standardized knowledge entries based on predefined templates includes: By connecting multiple heterogeneous data sources through a distributed data acquisition interface, the original records of successfully registered data intellectual property rights are automatically extracted to generate a multi-source original data set. The multi-source raw data set is cleaned and formatted. A rule-based data verification algorithm is used to remove duplicate records and correct format errors, generating a cleaned data set. Based on a predefined structured template, each record in the cleaned dataset is mapped to a standardized field to generate preliminary structured data; The initial structured data is semantically validated, and missing fields are detected and necessary information is automatically added using natural language processing technology, ultimately generating a standardized set of knowledge entries.

3. The method according to claim 2, characterized in that, The process involves using an embedding model to convert the standardized knowledge items into high-dimensional vector representations, constructing a professional knowledge base with a parent-child document association architecture. In this architecture, child documents focus on specific knowledge dimensions while parent documents maintain complete case information, including: The BGE-M3 embedding model is used to convert each item in the standardized knowledge item set into a multi-dimensional vector representation, generating a knowledge item vector set. For each knowledge item, multiple sub-documents are created according to predefined knowledge dimension division rules. Each sub-document focuses on a specific dimension, including data structure, application scenario or algorithm rules, generating a dimensional sub-document set. Create a corresponding parent document for each knowledge item. The parent document integrates the content of all child documents and maintains complete case information. Establish the relationship between parent and child documents through a unique identifier to generate a parent-child document system. The knowledge entry vector set, sub-document set, and parent-child related document system are stored in the Chroma vector database to build a professional knowledge base with multi-dimensional retrieval capabilities.

4. The method according to claim 3, characterized in that, The process involves generating query vectors based on the feature information of the data file to be processed, retrieving a set of relevant cases from the professional knowledge base through vector similarity retrieval, and calculating the matching score between each case and the features of the input data, including: Parse the metadata and content structure of the data file to be processed, automatically extract field names, data type distribution, numerical range and data sample characteristics, and generate a data feature description document; Using the same BGE-M3 embedding model as the knowledge base, the data feature description document is converted into a query vector, generating a standardized query vector. Multi-level vector similarity retrieval is performed in the professional knowledge base. The sub-document vectors are retrieved using standardized query vectors, and the complete cases are obtained through parent-child association. The cosine similarity algorithm is used to calculate the similarity score and generate preliminary retrieval results. A comprehensive matching analysis is performed on the preliminary search results. The final matching score for each case is calculated by combining feature overlap and semantic similarity. The relevant cases are then sorted in descending order of the scores to generate a set of related cases.

5. The method according to claim 4, characterized in that, The process involves multi-dimensionally fusing the relevant case set with input data features, and guiding a large language model to generate data intellectual property application materials containing algorithm rule descriptions and executable code through preset multi-round prompt templates, including: Context alignment analysis is performed between the relevant case set and the input data features to identify key feature matching points and differences, and to generate enhanced contextual information. Following a pre-defined multi-round prompt template sequence, the system sequentially loads prompts such as system role definitions, task specification descriptions, output format requirements, and algorithm design guidelines to generate a structured prompt sequence. The enhanced contextual information and structured prompt sequences are input into the large language model, and a draft of the application materials containing data names, source descriptions, application scenarios, and algorithm rule descriptions is generated through a chain reasoning mechanism. The initial draft of the application materials is converted into algorithm code, and executable Python data processing code is automatically generated based on the algorithm rule description, ultimately generating complete data intellectual property application materials.

6. The method according to claim 5, characterized in that, The process of automatically verifying the generated application materials and executing the data processing algorithms therein, followed by submitting a structured registration application to the intellectual property platform after ensuring the correct code execution through a self-healing execution mechanism, includes: Perform a format compliance check on the generated application materials, verify the completeness and format specifications of the required fields, and generate a material verification report; Run the data processing algorithms in the application materials in an isolated code execution environment, monitor the execution process in real time and capture runtime exceptions to generate code execution results; When a code execution error is detected, a self-healing execution mechanism is activated. The error log is analyzed using a large language model to generate a repair plan. The code is automatically corrected and then re-executed to generate corrected executable code. The verified application materials and successfully executed data processing algorithms are packaged into a structured data package, and the registration application is automatically submitted through the intellectual property platform API interface, generating a submission confirmation receipt.

7. A data intellectual property structure generation system based on large-scale model cognitive intelligence discovery, characterized in that, The system includes: The extraction module is used to extract registered intellectual property information from multiple data sources through the data acquisition layer, and to perform structured processing on the information based on a predefined template to generate standardized knowledge entries; The conversion module is used to convert the standardized knowledge items into high-dimensional vector representations using an embedding model, and to construct a professional knowledge base with a parent-child document association architecture, wherein the child documents focus on specific knowledge dimensions while the parent documents maintain complete case information; The acquisition module is used to generate query vectors based on the feature information of the data file to be processed, retrieve relevant case sets from the professional knowledge base through vector similarity retrieval, and calculate the matching degree score between each case and the input data features; The generation module is used to fuse the relevant case set with the input data features in multiple dimensions, and guide the large language model to generate data intellectual property application materials containing algorithm rule descriptions and executable code through preset multi-round prompt templates; The execution module is used to automatically verify the generated application materials and execute the data processing algorithms therein. After ensuring that the code runs correctly through a self-healing execution mechanism, it submits the structured registration application to the intellectual property platform.

8. The system according to claim 7, characterized in that, The extraction module is specifically used for: By connecting multiple heterogeneous data sources through a distributed data acquisition interface, the original records of successfully registered data intellectual property rights are automatically extracted to generate a multi-source original data set. The multi-source raw data set is cleaned and formatted. A rule-based data verification algorithm is used to remove duplicate records and correct format errors, generating a cleaned data set. Based on a predefined structured template, each record in the cleaned dataset is mapped to a standardized field to generate preliminary structured data; The initial structured data is semantically validated, and missing fields are detected and necessary information is automatically added using natural language processing technology, ultimately generating a standardized set of knowledge entries.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images