A data analysis generation method and system based on a code asset self-explanation protocol

Abstract

The application discloses a data analysis generation method and system based on a code asset self-explanation protocol, wherein the method comprises the following steps: S1, a knowledge encapsulation stage: converting scattered data analysis codes into knowledge units with standardized semantic descriptions; S2, a requirement receiving stage: mapping and converting a natural language semantic space into a contract space expression that can be understood by a system; S3, an asset addressing stage: searching and matching code assets, and performing integrity checking; S4, a granularity alignment stage: detecting whether there is a statistical granularity inconsistency problem in the multiple code assets and performing a compensatory aggregation operation; and S5, a logic synthesis stage: assembling the multiple code assets that have completed the granularity alignment. The application can realize the automation and precision closed loop from natural language requirements to code generation by giving the code the self-explanation capability, and can be widely applied to the fields of big data and artificial intelligence technologies.

Description

Technical Field

[0001] This invention relates to the fields of big data and artificial intelligence technology, and in particular to a data analysis and generation method and system based on a code asset self-interpretation protocol. Background Technology

[0002] Currently, enterprises mainly adopt the traditional model of "manually written SQL (Structured Query Language) + external document recording of specifications". Data analysis relies on the offline breakdown of natural language requirements, the recording of specifications in Wiki or Excel documents, and the maintenance of manual SQL code by engineers.

[0003] The main shortcomings of the existing technology are as follows: 1. Disconnect between documentation and facts (inconsistent definitions): Business definitions exist in the documentation, while execution logic exists in the code. The two are physically separated and lack a synchronization mechanism, causing the documentation to become invalid when the code is modified.

[0004] 2. Semantic black box (logic unreadable): Traditional SQL only describes the calculation steps and lacks semantic definition of entity meaning, data granularity and relationship.

[0005] 3. Knowledge gap (untraceable): There is a lack of end-to-end connection between the original requirements, SQL code and the final report results.

[0006] 4. Poor reusability (siloed development): The code logic is in the form of isolated scripts, lacking unified asset management.

[0007] The aforementioned shortcomings lead to problems such as decision-making risks, high data governance costs, and insufficient reliability of automatically generated SQL for enterprises. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the above-mentioned background technology and provide a data analysis and generation method and system based on a code asset self-interpretation protocol, so as to realize an automated and accurate closed loop from natural language requirements to code generation by endowing the code with "self-interpretation" capability.

[0009] This invention provides a data analysis generation method based on a self-interpreting code asset protocol, comprising the following steps: S1, Knowledge Encapsulation Stage: Transforming scattered data analysis code into knowledge units with standardized semantic descriptions, providing a foundation for subsequent automated synthesis; S2, Request Reception Stage: Receiving users' natural language data analysis requests and mapping them from the natural language semantic space to a contract space expression that the system can understand; S3, Asset Addressing Stage: Retrieving matching code assets from the knowledge base based on the semantic parsing results and verifying the integrity of their interface contracts; S4, Granularity Alignment Stage: Detecting whether there are statistical granularity inconsistencies among multiple code assets involved in the combination and automatically performing compensatory aggregation operations; S5, Logic Synthesis Stage: Assembling the multiple code assets that have completed granularity alignment into complete executable code.

[0010] In the above technical solution, the specific process of step S1 is as follows: S11, Protocol Embedding: Developers embed SDAP (Self-Describing Asset Protocol) protocol markers in the header comment area of ​​the data analysis code. This protocol is written in a structured format and is located between the @SDAP_BEGIN and @SDAP_END markers, and does not participate in the actual execution of the code; S12, Semantic Declaration: The code asset is comprehensively described through each module in the protocol: @Identity: Declares the globally unique identifier and business semantic name of the code asset, establishing a dual definition of technical identifier + business semantics; @Grain: Declares the business entity and statistical granularity level of the data, providing a basis for judgment for subsequent granularity consistency detection; @Interface: Defines the input parameter contract and semantic connection anchor, clarifying the parameter requirements and relationships of the code asset; @Mapping: Defines The mapping relationship between business enumeration values ​​and database physical values ​​enables the system to automatically convert natural language expressions into correct SQL conditions; @Outputs: Defines the name, type, and business meaning of output fields, enabling the system to automatically select output fields according to user needs; @Trace: Records the source, version, and evolution trajectory of knowledge assets, providing basic data for full-link traceability; S13, Pre-setting dynamic injection points: Reserves @DynamicFilter markers in the WHERE clause of the SQL code as anchor points for subsequent dynamic query conditions; S14, Asset entry: Code assets that have completed protocol implantation are indexed by the system and included in the knowledge base, forming standardized knowledge units that can be retrieved and called by the automation engine.

[0011] In the above technical solution, the specific process of step S2 is as follows: S21, Requirement Input: Input data analysis requirements in natural language form; S22, Semantic Parsing: The large language model inference engine performs semantic parsing on the user input to extract key business entities, statistical indicators, filtering conditions, and temporal semantics; S23, Semantic Alignment: Match the parsed business terms with the tags in the SDAP protocol to constrain the divergent generation of LLM within a predefined contract space and eliminate model illusion.

[0012] In the above technical solution, the specific process of step S3 is as follows: S31, Asset Retrieval: Based on the semantic parsing results, semantic retrieval is performed in the knowledge base using the identifier and business alias in the @Identity module to locate the set of code assets that meet the requirements; S32, Topology Discovery: The system constructs a topology graph of the connection relationship between assets by parsing the @Interface.join_key of each code asset, and identifies available association paths; S33, Parameter Validation and Completion: The system checks whether the required parameters defined in @Interface.inputs of each code asset have been provided by the user or can be automatically inferred. For time-related parameters, the system calls the business calendar for adaptive processing; S34, Semantic Value Conversion: The system automatically converts the business enumeration values ​​in the user input into physical values ​​in the database through the @Mapping module.

[0013] In the above technical solution, the specific process of step S4 is as follows: S41, Granularity Awareness: Parse the granularity information defined by the @Grain module in the SDAP protocol of each code asset, extract the business entities and statistical levels of each asset, and map them to the business logic topology tree; S42, Conflict Determination: The system compares the granularity vectors of each asset. If it detects that the granularity of two assets is inconsistent and there is an inclusion relationship in the topology tree, it is determined to be a granularity resolution mismatch conflict; S43, Logic Interception: Once a granularity conflict is detected, the system immediately intercepts the operation of directly executing the physical connection to avoid data multiplication caused by 1:N association; S44, Compensatory Aggregation: According to the target granularity requirements, inject aggregation operators into the logical fragments of high-resolution assets to force their data granularity to be aligned to the same level as the main asset.

[0014] In the above technical solution, the specific process of step S5 is as follows: S51, Topology consistency verification: Before assembly, the large language model checks whether the @Interface.join_key of each code asset matches. If no valid association key is defined in the protocol, the synthesis is forcibly interrupted and an exception feedback is triggered; S52, Logical stitching: Adopting a local generation and overall reuse strategy, the original SQL fragments of each code asset are reused. The large language model only generates the necessary logical glue layer and injects the dynamic query conditions into the reserved position of @DynamicFilter; S53, Output field selection: According to the definition of the @Outputs module, the output fields are automatically selected in combination with user requirements, and business explanations are provided through aliases.

[0015] The above technical solution also includes step S6, the verification and output stage: the synthesized code is fully verified to ensure its correctness in three dimensions: business semantics, mathematical logic and physical execution, and then output after attaching traceability information.

[0016] In the above technical solution, the specific process of step S6 is as follows: S61, Syntax and Type Check: Pre-parse the generated SQL, compare it with the field types defined in the @Outputs module, and verify whether numeric and character types are mixed and whether function calls are legal; S62, Logical Consistency Assertion: Combine the granular contract execution logic self-check of the @Grain module to detect whether there is a risk of many-to-many association and whether necessary aggregation operators are missing. If a risk is detected, the system automatically triggers rewriting; S63, Source Fingerprint Mounting: Based on the source information recorded in the @Trace module, attach full-link source information to the final output; S64, Result Output: Output the fully verified executable code, along with explanations of the business meaning of the output fields and source links.

[0017] In the above technical solution, step S1 introduces a knowledge atomization encapsulation mechanism oriented towards code logic units, which uses the smallest reusable computing unit as the basic organizational granularity.

[0018] The present invention also provides a data analysis and generation system based on a code asset self-interpretation protocol, comprising a computer device having a processor and a memory, wherein the processor processes a computer program stored in the memory, the computer program being capable of executing a data analysis and generation method based on a code asset self-interpretation protocol.

[0019] The present invention provides a data analysis and generation method and system based on a code asset self-interpretation protocol, which has the following beneficial effects: 1. Extremely high consistency: Knowledge assets physically flow with the code, and modifying the code is equivalent to modifying the protocol, which completely solves the problem of outdated documents.

[0020] 2. Significant leap in generation accuracy: Through explicit constraints on join_key and grain, the accuracy of generating complex logic from large models has been improved from the traditional 60% to over 95%.

[0021] 3. Reduced development costs and increased efficiency: Implicit optional protocols reduce the amount of metadata maintenance, and the mapping function allows non-technical users to accurately call the underlying code logic through natural language.

[0022] 4. Closed-loop traceability: The @Trace tag in the protocol enables full-link tracing of "requirements-code-data". Attached Figure Description

[0023] Figure 1 This is an overview diagram of Embodiment 1 of the data analysis and generation method based on the code asset self-interpretation protocol of the present invention; Figure 2 This is an overall flowchart of Embodiment 2 of the data analysis and generation method based on the code asset self-interpretation protocol of the present invention; Figure 3 This is a flowchart illustrating the semantic alignment and contract verification process of phases three and four in embodiment 2 of the data analysis and generation method based on the code asset self-interpretation protocol of the present invention. Figure 4 This is a flowchart illustrating the dynamic injection and closed-loop process of stages five and six in Embodiment 2 of the data analysis and generation method based on the code asset self-interpretation protocol of the present invention. Figure 5 This is an architecture diagram of the data analysis and generation system based on the code asset self-interpretation protocol of this invention. Detailed Implementation

[0024] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments, but these embodiments should not be construed as limiting the present invention.

[0025] Specifically, this invention relates to a system based on a Large Language Model (LLM) that utilizes a code self-interpretation protocol to automate the data analysis criteria and code closed-loop synthesis.

[0026] The core of this invention lies in providing a complete workflow from natural language requirement input to executable code output. This workflow, based on the Self-Interpreting Code Asset Protocol (SDAP) and using a large language model as the inference engine, achieves an end-to-end closed loop of "requirement input → semantic parsing → contract verification → granular alignment → logic synthesis → verification output". The following detailed description of the invention's operation is provided in conjunction with specific embodiments.

[0027] Example 1 See Figure 1This invention relates to a data analysis and generation method based on a code asset self-interpretation protocol. The overall workflow includes the following six stages: [Phase 1] Knowledge Encapsulation Phase: Code Asset Registration Based on SDAP Protocol ↓ [Phase Two] Demand Reception Phase: Natural Language Input and Semantic Parsing ↓ [Phase Three] Asset Location Phase: Contract-Based Semantic Matching and Parameter Verification ↓ [Phase Four] Granularity Alignment Stage: Heterogeneous Granularity Conflict Detection and Compensatory Aggregation ↓ [Phase Five] Logical Composition Phase: Deterministic Code Assembly Based on Contracts ↓ [Phase Six] Verification and Output Phase: Post-synthesis verification, source tracing and mounting, and result output. Example 2 This embodiment is basically the same as Embodiment 1, except that: See Figure 2 The present invention relates to a data analysis and generation method based on a code asset self-interpretation protocol. The specific process is as follows: Phase 1: Knowledge Encapsulation Phase – Code Asset Registration Based on SDAP Protocol Objective: To transform scattered data analysis code into knowledge units with standardized semantic descriptions, providing an understandable, searchable, and assembleable foundation for subsequent automated synthesis.

[0028] Execution steps: Protocol embedding: Developers embed SDAP protocol tags in the header comment area of ​​data analysis code (such as SQL, Python scripts). This protocol is written in a structured format (such as YAML) and is located between the @SDAP_BEGIN and @SDAP_END tags; it does not participate in the actual execution of the code.

[0029] Semantic Declaration: A comprehensive description of the code assets through the various modules in the protocol: @Identity: Declares a globally unique identifier (id) and a business semantic name (name) for code assets, establishing a dual definition of "technical identifier + business semantic".

[0030] @Grain: Declares the business entity and statistical granularity level of the data, providing a basis for subsequent granularity consistency checks.

[0031] @Interface: Defines the input parameter contract (inputs) and semantic join key (join_key), clarifying the parameter requirements and relationships of the code asset.

[0032] @Mapping: Defines the mapping relationship between business enumeration values ​​and database physical values, enabling the system to automatically convert natural language expressions into correct SQL conditions.

[0033] @Outputs: Defines the name, type, and business meaning of the output fields, enabling the system to automatically select the output fields according to user needs.

[0034] @Trace: Records the source, version, and evolution trajectory of knowledge assets, providing basic data for full-chain traceability.

[0035] Pre-defined dynamic injection points: Reserve the @DynamicFilter marker in the WHERE clause of the SQL code as an anchor point for inserting subsequent dynamic query conditions.

[0036] Asset entry: Code assets that have completed protocol integration are indexed by the system and included in the knowledge base, forming standardized knowledge units that can be retrieved and invoked by the automation engine.

[0037] Phase Two: Demand Reception Phase – Natural Language Input and Semantic Parsing Objective: To receive users' natural language data analysis requests and map them from the natural language semantic space into a contract space expression that the system can understand.

[0038] Execution steps: Input requirements: Users input their data analysis requirements in natural language.

[0039] Semantic parsing: The large language model inference engine performs semantic parsing on user input to extract key business entities, statistical indicators, filtering conditions, and time semantics.

[0040] Semantic alignment: The system matches parsed business terms with tags in the SDAP protocol. For example, using the @Identity.name and @Mapping modules, "institutional client" is mapped to the corresponding code assets and database codes. This process constrains the divergent generation of LLM within a predefined contract space, eliminating model illusions at the source.

[0041] Phase Three: Asset Location Phase – Contract-Based Semantic Matching and Parameter Validation (See also...) Figure 3 Objective: Based on the semantic parsing results, retrieve matching code assets from the knowledge base and perform integrity verification on their interface contracts.

[0042] Execution steps: Asset retrieval: Based on the semantic parsing results, the system performs semantic retrieval in the knowledge base using identifiers and business aliases in the @Identity module to locate the set of code assets that meet the requirements.

[0043] Topology discovery: The system automatically constructs a topology graph of connections between assets by parsing the @Interface.join_key of each code asset, and identifies available association paths.

[0044] Parameter validation and completion: The system checks whether the required parameters defined in `@Interface.inputs` of each code asset have been provided by the user or can be automatically inferred. For time-related parameters, the system uses the business calendar for adaptive processing.

[0045] Semantic value conversion: The system uses the @Mapping module to automatically convert the business enumeration values ​​in user input into physical values ​​in the database.

[0046] Phase Four: Granularity Alignment Phase – Heterogeneous Granularity Conflict Detection and Compensatory Aggregation Objective: To detect inconsistencies in statistical granularity among multiple code assets involved in the aggregation, and to automatically perform compensatory aggregation operations when necessary.

[0047] Execution steps: Granularity awareness: The system parses the granularity information defined in the @Grain module of the SDAP protocol of each code asset, extracts the business entities and statistical levels of each asset, and maps them to the business logic topology tree.

[0048] Conflict determination: The system compares the granularity vectors of each asset. If two assets are found to have inconsistent granularity and contain each other in the topology tree, it is determined to be a "granularity resolution mismatch" conflict.

[0049] Logical interception: Once a granularity conflict is detected, the system immediately intercepts operations that directly execute physical connections to avoid data multiplication caused by 1:N associations.

[0050] Compensatory aggregation: Based on the target granularity requirements, the system automatically injects aggregation operators (such as SUM, COUNT, ROW_NUMBER, etc.) into the logical fragments of high-resolution assets, forcibly aligning their data granularity to the same level as the main asset.

[0051] Phase 5: Logic Composition Phase – Contract-Based Deterministic Code Assembly (See also...) Figure 4 Objective: To assemble multiple granularly aligned code assets into a complete executable code.

[0052] Execution steps: Topology consistency check: Before assembly, the large language model checks whether the `@Interface.join_key` of each code asset matches. If a valid join key is not defined in the protocol, the system forcibly interrupts the synthesis and triggers an exception feedback.

[0053] Logical stitching: The system adopts a "local generation, overall reuse" strategy. The original SQL fragments of each code asset are directly reused, and the large language model only generates the necessary logical glue layer (such as JOIN statements), and injects dynamic query conditions into the reserved positions of @DynamicFilter.

[0054] Output field selection: The system automatically selects output fields based on the definition of the @Outputs module and user requirements, and provides business explanations through aliases.

[0055] Phase Six: Verification and Output Phase – Post-synthesis verification, source tracing and mounting, and result output Objective: To perform comprehensive verification of the synthesized code to ensure its correctness in three dimensions: business semantics, mathematical logic, and physical execution, and output it after attaching traceability information.

[0056] Execution steps: Syntax and type checks: The system pre-parses the generated SQL and checks against the field types defined in the @Outputs module to verify whether numeric and character types are mixed and whether function calls are valid.

[0057] Logical consistency assertion: The system performs logical self-checks using the granular contract of the @Grain module to detect the existence of many-to-many relationships and the risk of missing necessary aggregation operators. If a risk is detected, the system automatically triggers a rewrite.

[0058] Source fingerprint mounting: Based on the source information recorded in the @Trace module, the system adds full-link source information to the final output.

[0059] Output results: The system outputs fully validated executable code, along with explanations of the business meanings of the output fields and traceability links.

[0060] in, Detailed explanation of the Self-Interpreting Code Asset Protocol (SDAP): In Phase 1 of the above workflow, the system implements knowledge encapsulation by embedding the SDAP protocol at the beginning of the code file. This protocol, written in a structured format (such as YAML), is located between the @SDAP_BEGIN and @SDAP_END tags and is used for semantic annotation of the code. The SDAP protocol consists of six semantic modules, each playing a different role in the system workflow.

[0061] 1. The correspondence between the functions of each module and the process stages is shown in Table 1: Table 1. Correspondence between the functions of each module and the process stages

[0062] 2. Core Mechanisms and Algorithms 2.1 Knowledge Atomization Encapsulation Mechanism In this invention, to achieve structured management and semantic representation of data analysis code assets, a knowledge atomic encapsulation mechanism oriented towards code logic units is introduced. This mechanism uses the "smallest reusable computational unit" as the basic organizational granularity, transforming the originally discrete data analysis code into knowledge units with clear semantic boundaries and standard interface constraints.

[0063] 2.1.1 Entity Attributes and Granular Contract Declaration Mechanism This mechanism defines the "position" of each code logic unit in the business semantic space, essentially constructing a semantic coordinate system oriented towards data analysis knowledge. Based on this granularity contract, the system can perform dimensional consistency checks, automatically detect granularity conflicts, assess data fan-out risks, and automatically insert aggregation logic for granularity alignment when necessary.

[0064] 2.1.2 Topology Interface and Association Contract Declaration Mechanism This mechanism defines the connection methods between different code logic units, essentially constructing a topology description system oriented towards data analysis logic. By standardizing the definition of connection keys, the system can automatically build connection relationships between multiple code assets, effectively avoiding problems such as data bloat caused by non-equi-joins and data mismatch caused by incorrectly associated fields.

[0065] 2.2 Granularity-sensitive semantic consistency alignment operator This invention proposes a heterogeneous granularity automatic alignment algorithm based on semantic contract constraints to address issues such as dimensionality collapse, index distortion, and computational drift caused by inconsistent data observation granularity during the automated assembly process of multiple data calibers. The algorithm constructs a closed-loop processing mechanism of "perception-determination-compensation-verification".

[0066] 2.2.1 Granular Feature Extraction and Spatial Mapping (Perception Stage) The system extracts the core granular features of each code asset involved in the calculation by parsing the @Grain tag defined in the SDAP protocol, and encodes them into a structured "granular vector", which is then mapped to the system's predefined business logic topology tree.

[0067] 2.2.2 Dimensional Conflict Determination and Path Conflict Detection (Determination Phase) The system executes a granularity consistency determination function to perform conflict analysis on multiple data assets involved in the combination. Let the two data assets involved in the calculation be A and B. When A.grain ≠ B.grain and the two have an inclusion relationship in the topology tree, the system determines it as a "granularity resolution mismatch" conflict and immediately triggers a logical interception strategy.

[0068] 2.2.3 Dynamic synthesis of compensating aggregation operators (synthesis stage) After determining the granularity alignment path, the system automatically injects aggregation operators (such as SUM, COUNT, ROW_NUMBER, etc.) into the logical fragments of high-resolution data assets according to the primary key and target granularity requirements defined in the protocol, thereby achieving forced alignment of data granularity.

[0069] 2.2.4 Closed-loop verification and consistency check After logical synthesis is completed, the system introduces a result consistency verification mechanism, which compares the changes in the uniqueness distribution of the primary key, verifies the consistency between the number of records before and after alignment and the aggregation result, and checks whether the "equi-association" constraint is satisfied.

[0070] 2.3 Protocol-Contract-Driven Logic Synthesis and Accuracy Guarantee Mechanism This invention uses a large language model inference engine as the core of semantic understanding and logical orchestration, but by introducing a strong constraint mechanism of code asset self-interpretation protocol, the generation behavior of the model is limited to a controllable range.

[0071] 2.3.1 Mapping and Transformation from Semantic Space to Contract Space After receiving natural language input from the user, the system first performs a "semantic alignment" process: mapping the user input to the business semantic space, and then mapping it to the code asset set through protocol tags. This mechanism constrains the model generation space within the predefined code asset set, eliminating the illusion problem caused by free model generation.

[0072] 2.3.2 Deterministic Assembly Mechanism of Logical Structure During the logic generation phase, the large language model acts as a "logic orchestrator," strictly adhering to the interface contract declarations in the SDAP protocol for path addressing. The system adopts a "partial generation, overall reuse" strategy, directly reusing original SQL code snippets, and generating only the necessary logical glue layer from the model.

[0073] 2.3.3. Rule-based post-synthesis verification mechanism After synthesis, the system introduces a formal verification mechanism, including syntax and type consistency checks and logical consistency assertions. If a risk is detected, the system automatically triggers a granularity-sensitive alignment operator to rewrite the logic until the contract constraints are met.

[0074] The "Core Mechanisms and Algorithms" section explains the underlying implementation mechanisms of the preceding steps, including SDAP protocol definition, code asset accumulation, natural language parsing, asset portfolio creation, SQL generation, verification, and tracing. The preceding process descriptions outline "what the system does and in what order," while the core mechanisms and algorithms section explains "why the system can do this and what rules allow it to complete it automatically." See Table 2 for the specific correspondence. Table 2. Correspondence between core mechanism algorithms and process descriptions

[0075] This can be further summarized as: The preceding process outlines the business processing chain, while the core mechanism algorithm is embedded in key nodes of this chain, playing a role in constraint, judgment, rewriting, and verification. Therefore, the core mechanism and algorithm do not execute the process independently, but are embedded in the underlying control mechanisms within the aforementioned SDAP protocol parsing, code asset retrieval, logic combination, SQL generation, and result verification process nodes. The preceding process defines the system's processing steps from requirements to code generation, while the core mechanism and algorithm define the semantic constraint rules, interface matching rules, granular conflict handling rules, and result verification rules for each step. Through these mechanisms, the system can transform natural language requirements into a protocol-constrained deterministic code synthesis process, thereby achieving accuracy, consistency, and traceability in automatically generated SQL.

[0076] 3. Supporting technical content: Adaptive strategies and source tracing 3.1 Business Calendar-Driven Date Evolution Strategy To address the issue of time ambiguity, this system introduces a "date operator" mechanism: mapping the vague terms "yesterday" and "latest" to strategy_options in the protocol (such as the T-1 trading day strategy); the system has a built-in financial trading calendar, which automatically executes backtracking logic when user requests trigger non-trading days.

[0077] 3.2 Dynamic Command Precision Injection Mechanism The system achieves non-destructive logic extension by pre-setting "semantic anchors" (@DynamicFilter) in the code. After AI identifies the user's specific needs, it precisely "stitches" the generated conditional instructions into the reserved locations.

[0078] 3.3 Closed-loop traceability and fingerprint tracking When outputting the final data results, the system will forcibly attach a "source fingerprint". This fingerprint contains end-to-end information from the original business definition and Git repository version to the AI ​​synthesis parameters.

[0079] Example 3 Scenario Description: Cross-system, cross-granularity institutional asset verification Requirement: A banking business manager requests statistics on "institutional clients in a certain region whose assets changed by more than 20% in the previous trading day".

[0080] Phase 1: Knowledge Encapsulation (Completed) The developers have pre-packaged the two code assets, "Customer Basic Information" and "Asset Transaction History," using the SDAP protocol. Specifically: The `@Grain` property of "Customer Basic Information" declares `entity="Customer"` and `level="Customer Level"`, and `@Interface.join_key` declares `CLIENT_ID` as the join key.

[0081] The "Asset Flow" @Grain declares entity="transaction" and level="detail level", and @Interface.join_key declares CLIENT_ID as the join key.

[0082] The @Mapping attribute of “Asset Flow” defines the mapping relationship between “Institutional Clients” and ORGAN_FLAG='1'.

[0083] The @Interface.inputs method for “Asset Flow” defines ETL_DATE as a required parameter, with its strategy being T-1_TRADING.

[0084] Phase Two: Request Reception and Semantic Parsing After the user inputs their natural language request, the large language model inference engine performs semantic parsing and extracts the following key information: Business entities: "Customers" and "Assets".

[0085] Statistical indicator: "Asset changes exceeding 20%".

[0086] Filter criteria: "a certain region" and "institutional clients".

[0087] Time semantics: "previous trading day".

[0088] The system uses the @Identity.name and @Mapping modules to map "institutional clients" to corresponding code assets and database codes, and "a certain region" to corresponding region codes.

[0089] Phase 3: Asset Addressing and Parameter Verification Based on the semantic parsing results, the system retrieved two code assets, "Customer Basic Information" and "Asset Transaction History," through the @Identity module. @Interface.join_key confirmed that both declared CLIENT_ID as the association key, indicating a valid join path. Simultaneously, the system checked @Interface.inputs and found that ETL_DATE was a required parameter with a strategy of T-1_TRADING. Since it was currently Monday, the system automatically invoked the transaction calendar, resolving the date parameter to last Friday.

[0090] Phase Four: Granularity Alignment The system analyzed the @Grain information of the two code assets and found that "Customer Basic Information" was at the customer level, while "Asset Transaction History" was at the detail level. There was a typical 1:N inclusion relationship between the two, which the system identified as a "granularity resolution mismatch" conflict. The system immediately intercepted the direct JOIN operation and automatically injected the GROUP BY CLIENT_ID aggregation operator into the logic fragment of "Asset Transaction History" to ensure that asset changes were statistically recorded at the customer level, preventing data doubling.

[0091] Phase 5: Logical Synthesis The system performs a topology consistency check on the `@Interface.join_key` of each code asset to confirm that the CLIENT_ID matches. Subsequently, the system adopts a "partial generation, overall reuse" strategy, reusing the original SQL fragments and generating only the JOIN statement as a logical glue layer, and injecting dynamic conditions such as "a certain region" and "institutional clients" into the reserved positions of `@DynamicFilter`.

[0092] Phase Six: Output Verification The system performs a comprehensive validation of the synthesized SQL: Syntax and type checks: Verify the consistency of output field types against the @Outputs module.

[0093] Logical consistency assertion: Combined with the @Grain module, it is confirmed that the granularity alignment operator has been correctly injected and there is no data bloat path.

[0094] Source fingerprint mounting: Based on the @Trace module, it adds full-link source traceability information including the original requirement identifier, code asset version, and Git commit hash.

[0095] Finally, the system outputs fully validated executable SQL, along with explanations of the business meanings of the output fields and source links.

[0096] Example 4 See Figure 5 The present invention is a data analysis and generation system based on a code asset self-interpretation protocol, comprising the following components: Knowledge encapsulation module: Transforms scattered data analysis code into knowledge units with standardized semantic descriptions, providing an understandable, searchable, and assemblable foundation for subsequent automated synthesis; Request receiving module: Receives users' natural language data analysis requests and maps them from the natural language semantic space into a contract space expression that the system can understand; Asset addressing module: Based on the semantic parsing results, retrieve matching code assets from the knowledge base and perform integrity verification on their interface contracts; Granularity alignment module: Detects inconsistencies in statistical granularity among multiple code assets involved in the combination and automatically performs compensatory aggregation operations; Logic synthesis module: Assembles multiple code assets that have been aligned at the granularity level into complete executable code; Verification output module: Performs comprehensive verification on the synthesized code to ensure its correctness in three dimensions: business semantics, mathematical logic, and physical execution, and outputs it after attaching traceability information.

[0097] In summary, this invention achieves native integration of business semantics, interface contracts, and execution logic at the physical code level by constructing a self-interpreting code asset protocol. By endowing code with "self-interpretation" capabilities, it realizes an automated and precise closed loop from natural language requirements to code generation.

[0098] Its core objective and technical principle are: Establish a new governance model of "code as semantics": change the traditional binary disconnect between "documentation of definitions and code implementation of logic". By directly internalizing business definitions in the code header, code becomes a Wiki and definition, eliminating the gap in definitions at its physical root.

[0099] Constructing a controlled automated synthesis pipeline: Utilizing a large language model (LLM) as an inference engine to parse the strongly constrained contracts in the SDAP protocol, transforming the role of AI from "black-box generation" to "contract-based precise synthesis".

[0100] Ensuring data consistency and logical accuracy: Through protocol-driven automated closed loops, the system ensures that the data results produced by the system conform to the enterprise's unified standards in terms of business dimensions, mathematical granularity, and time rules in complex business scenarios.

[0101] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0102] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

Claims

1. A data analysis and generation method based on a code asset self-interpretation protocol, characterized in that: Includes the following steps: S1. Knowledge Encapsulation Stage: Transforming scattered data analysis code into knowledge units with standardized semantic descriptions, providing a foundation for subsequent automated synthesis; S2, Request Reception Phase: Receive users' natural language data analysis requests and map them from the natural language semantic space into a contract space expression that the system can understand; S3, Asset Addressing Phase: Based on the semantic parsing results, retrieve matching code assets from the knowledge base and perform integrity verification on their interface contracts; S4, Granularity Alignment Stage: Detects whether there are inconsistencies in statistical granularity among multiple code assets involved in the combination, and automatically performs compensatory aggregation operations; S5, Logic Synthesis Stage: Assemble multiple code assets that have been aligned at the granularity level into complete executable code.

2. The data analysis and generation method based on the code asset self-interpretation protocol according to claim 1, characterized in that: The specific process of step S1 is as follows: S11, Protocol Embedding: Developers embed SDAP protocol tags in the header comment area of ​​the data analysis code. The protocol is written in a structured format and is located between the @SDAP_BEGIN and @SDAP_END tags. It does not participate in the actual execution of the code. S12. Semantic Declaration: A comprehensive description of the code assets through the various modules in the protocol: @Identity: Declares a globally unique identifier and business semantic name for code assets, establishing a dual definition of technical identifier + business semantics; @Grain: Declares the business entity and statistical granularity level of the data, providing a basis for subsequent granularity consistency checks; @Interface: Defines the input parameter contract and semantic connection anchors, clarifying the parameter requirements and relationships of the code asset; @Mapping: Defines the mapping relationship between business enumeration values ​​and database physical values, enabling the system to automatically convert natural language expressions into correct SQL conditions; @Outputs: Defines the name, type, and business meaning of the output fields, enabling the system to automatically select the output fields according to user needs; @Trace: Records the source, version, and evolution trajectory of knowledge assets, providing basic data for full-chain traceability; S13. Pre-setting dynamic injection points: Reserve the @DynamicFilter marker in the WHERE clause of the SQL code as the insertion anchor point for subsequent dynamic query conditions; S14. Asset Entry: Code assets that have completed protocol integration are indexed by the system and included in the knowledge base, forming standardized knowledge units that can be retrieved and invoked by the automation engine.

3. The data analysis and generation method based on the code asset self-interpretation protocol according to claim 2, characterized in that: The specific process of step S2 is as follows: S21. Input Requirements: Input data analysis requirements in natural language format; S22. Semantic parsing: The large language model inference engine performs semantic parsing on user input to extract key business entities, statistical indicators, filtering conditions, and time semantics. S23. Semantic Alignment: Match the parsed business terms with the tags in the SDAP protocol to constrain the divergent generation of LLM within a predefined contract space and eliminate model illusion.

4. The data analysis and generation method based on the code asset self-interpretation protocol according to claim 3, characterized in that: The specific process of step S3 is as follows: S31. Asset Retrieval: Based on the semantic parsing results, semantic retrieval is performed in the knowledge base using identifiers and business aliases in the @Identity module to locate the set of code assets that meet the requirements. S32. Topology Discovery: The system constructs a topology graph of the connection relationships between assets by parsing the @Interface.join_key of each code asset, and identifies available association paths; S33. Parameter validation and completion: The system checks whether the required parameters defined in @Interface.inputs of each code asset have been provided by the user or can be automatically inferred. For time-related parameters, the system calls the business calendar for adaptive processing. S34. Semantic value conversion: The system uses the @Mapping module to automatically convert the business enumeration values ​​in the user input into physical values ​​in the database.

5. The data analysis and generation method based on the self-interpreting protocol of code assets according to claim 4, characterized in that: The specific process of step S4 is as follows: S41, Granularity Awareness: Parse the granularity information defined by the @Grain module in the SDAP protocol of each code asset, extract the business entities and statistical levels of each asset, and map them to the business logic topology tree; S42. Conflict determination: The system compares the granularity vectors of each asset. If it detects that the granularity of two assets is inconsistent and there is an inclusion relationship in the topology tree, it is determined to be a granularity resolution mismatch conflict. S43. Logical Interception: Once a granularity conflict is detected, the system immediately intercepts the operation that directly executes the physical connection to avoid data multiplication caused by 1:N association; S44 Compensatory Aggregation: Injects aggregation operators into logical fragments of high-resolution assets according to target granularity requirements, forcibly aligning their data granularity to the same level as the main asset.

6. The data analysis and generation method based on the code asset self-interpretation protocol according to claim 5, characterized in that: The specific process of step S5 is as follows: S51. Topology Consistency Check: Before assembly, the large language model checks whether the @Interface.join_key of each code asset matches. If a valid association key is not defined in the protocol, the synthesis is forcibly interrupted and an exception feedback is triggered. S52, Logical stitching: Adopting a strategy of local generation and overall reuse, the original SQL fragments of each code asset are reused, the large language model only generates the necessary logical glue layer, and the dynamic query conditions are injected into the reserved positions of @DynamicFilter; S53. Output Field Selection: Based on the definition of the @Outputs module and combined with user requirements, the output fields are automatically selected, and business explanations are provided through aliases.

7. The data analysis and generation method based on the code asset self-interpretation protocol according to claim 6, characterized in that: It also includes step S6, the verification output stage: the synthesized code is fully verified to ensure its correctness in three dimensions: business semantics, mathematical logic and physical execution, and then output after attaching traceability information.

8. The data analysis and generation method based on the code asset self-interpretation protocol according to claim 7, characterized in that: The specific process of step S6 is as follows: S61. Syntax and Type Check: Pre-parse the generated SQL and check whether numeric and character types are mixed and whether function calls are valid by comparing them with the field types defined in the @Outputs module. S62. Logical consistency assertion: Combines the granular contract execution logic self-check of the @Grain module to detect the risk of many-to-many associations and missing necessary aggregation operators. If a risk is detected, the system will automatically trigger a rewrite. S63, Source Fingerprint Mounting: Based on the source information recorded in the @Trace module, append full-link source information to the final output; S64. Output Results: Output fully validated executable code, along with explanations of the business meanings of the output fields and traceability links.

9. The data analysis and generation method based on the code asset self-interpretation protocol according to claim 8, characterized in that: Step S1 introduces a knowledge atomization encapsulation mechanism oriented towards code logic units, which uses the smallest reusable computing unit as the basic organizational granularity.

10. A data analysis and generation system based on a code asset self-interpretation protocol, comprising a computer device having a processor and a memory, wherein the processor processes computer programs stored in the memory, characterized in that: The computer program is capable of executing the data analysis and generation method based on the code asset self-interpretation protocol as described in any one of claims 1 to 9.

Images