Active probe based enterprise database field semantic validation method and system

Abstract

The application provides an enterprise-level database field semantic confirmation method and system based on an active probe, including: determining a data prototype corresponding to a field value of a target field in a database; determining a target name semantic of the target field; determining a plurality of field value candidate semantics of the target field based on the data prototype, the target name semantic, and context information corresponding to the target field; determining a first observable difference of the plurality of field value candidate semantics; determining a first probe structured query statement from a probe library based on the first observable difference, the context information, and the data prototype; and determining a target field value semantic from the plurality of field value candidate semantics based on a query result of the first probe structured query statement. The embodiments of the application reduce the risk of semantic misjudgment through active probe query verification, and use the target name semantic of the target field and the target field value semantic to enable a large language model to understand the content of the database, thereby improving the accuracy of the large language model in real complex task execution.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence technology, specifically relating to an enterprise-level database field semantic verification method and system based on active probes. Background Technology

[0002] With the groundbreaking progress of Large Language Model (LLM) in the field of code generation, Natural Language to Structured Query Language (NL2SQL) technology is regarded as an important driving force for the modernization of enterprise business intelligence.

[0003] However, user-defined databases currently contain content that large language models cannot understand. For example, enterprise databases may have irregular field names, unclear field value semantics, and missing implicit relationships, making it difficult for upper-layer applications to accurately understand database semantics and resulting in low accuracy in the execution of real complex tasks. Summary of the Invention

[0004] This application proposes an enterprise-level database field semantic verification method and system based on active probes, which can solve the technical problem in related technologies that the database contains content that large language models cannot understand, resulting in low accuracy of NL2SQL models in the execution of real complex tasks.

[0005] The first aspect of this application provides a method for semantic verification of enterprise-level database fields based on active probes, including: Determine the data prototype corresponding to the value of the target field in the database; Determine the target name semantics of the target field; Based on the data prototype, the target name semantics, and the context information corresponding to the target field, multiple candidate semantics for the field values ​​of the target field are determined; Determine the first observable difference in the semantics of the candidate field values; Based on the first observable difference, the context information, and the data prototype, a first probe structured query statement is determined from the probe library; The target field value semantics are determined from the candidate semantics of the multiple field values ​​based on the query results of the first probe structured query statement.

[0006] A second aspect of this application provides an enterprise-level database field semantic verification system based on active probes, comprising: The scout agent is used to determine the data prototype corresponding to the field value of a target field in the database. A linguist agent is used to determine multiple candidate semantics of field values ​​for a target field based on the data prototype, the target name semantics, and context information corresponding to the target field; determine a first observable difference between the multiple candidate semantics of field values; determine a first probe structured query statement from the probe library based on the first observable difference, the context information, and the data prototype; and determine the target field value semantics from the multiple candidate semantics of field values ​​based on the query result of the first probe structured query statement.

[0007] The technical solutions provided in this application embodiment have at least the following technical effects or advantages: This application proposes an enterprise-level database field semantic verification method and system based on active probes, including: determining the data prototype corresponding to the field value of a target field in the database; determining the target name semantics of the target field; determining multiple candidate field value semantics of the target field based on the data prototype, the target name semantics, and the context information corresponding to the target field; determining a first observable difference among the multiple candidate field value semantics; determining a first probe structured query statement from a probe library based on the first observable difference, context information, and data prototype; and determining the target field value semantics from the multiple candidate field value semantics based on the query result of the first probe structured query statement. The embodiments of this application reduce the risk of semantic misjudgment through active probe query verification, and improve the accuracy of large language models in performing real-world complex tasks by enabling large language models to understand the content of the database through the target name semantics and target field value semantics of the target field.

[0008] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0009] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 The illustration shows a flowchart of an enterprise-level database field semantic verification method based on active probes, provided in an exemplary embodiment of this application. Figure 2 A flowchart illustrating a data prototype determination process provided in an exemplary embodiment of this application is shown. Figure 3 This illustration shows a flowchart of a method for determining the semantics of a target field value, provided by an exemplary embodiment of this application. Figure 4This illustration shows a flowchart of a method for determining the semantics of a target name, provided by an exemplary embodiment of this application. Figure 5 This illustration shows a schematic diagram of the structure of an enterprise-level database field semantic verification system based on an active probe, provided in an exemplary embodiment of this application. Detailed Implementation

[0010] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0011] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0012] Building upon the aforementioned background, current databases are rife with non-standard naming conventions and implicit relationships, making it difficult for NL2SQL models to correctly understand user intent. For example, table and column names often use abbreviations, initials of pinyin, or meaningless numbers, such as "T_YW_01" (business table 01), "kh_nm" (customer name), and "je" (amount). Traditional large models struggle to understand their true meaning, resulting in extremely low accuracy of current NL2SQL models in executing real-world complex tasks.

[0013] Currently, the mainstream NL2SQL technology approach is mainly static schema joining, which assumes that the database itself provides sufficient semantic information. Methods based on this assumption include: 1. Metadata-based hinting engineering: First, extract the metadata (name, comments, etc.) of the tables and columns from the database, and then concatenate it into the hints of the LLM to guide the model to generate SQL.

[0014] 2. Pattern dictionary / knowledge base: Use LLM to parse source code or existing documents to generate descriptions of the data dictionary, or vectorize table information for model retrieval and matching.

[0015] However, these passive methods are not ideal in reality, with low recognition accuracy and limitations as follows: 1. Semantic Deficiency: If the database lacks clear comments or documentation, the model has no basis to rely on. For example, a system may have multiple tables containing a "status" field, but with different business semantics. Static methods cannot distinguish these differences based on the data content.

[0016] 2. Naming Confusion: Static schema linking assumes that names reflect meaning, but many enterprise databases have confusing naming conventions. For example, as mentioned above, "kh" represents "customer" and "je" represents "amount." The model has difficulty making judgments based on these abbreviations, and simply relying on name matching can lead to incorrect associations.

[0017] 3. Implicit Relationships: For performance optimization, modern data warehouses often do not establish physical foreign key constraints. When generating JOIN statements, the model can only guess based on column names, often leading to incorrect associations between user_id and creator_id, or missing paths that should only be joined through intermediate tables.

[0018] 4. Lack of validation: Existing automated data dictionary generation solutions (such as IronCrow AI's US 18 / 617,221 patent application) typically only compile existing information without verifying whether these inferences are consistent with real data. The lack of intermediate layer execution means the NL2SQL model directly faces raw, "dirty" data.

[0019] Furthermore, existing technologies attempt to improve database understanding through multi-agent semantic analysis. For example, multiple autonomous agent modules work collaboratively, including a Scout agent for text data fingerprinting and statistical analysis, a Linguist agent for determining language patterns and labels, and a Relation agent for identifying entity relationships using natural language processing and set theory methods, storing the extracted information in a unified knowledge base. However, these solutions only address the understanding and knowledge extraction of natural language text and do not focus on the semantic problems of relational databases. They neither address the deciphering of non-standard naming conventions such as pinyin abbreviations, nor verify semantic hypotheses through database queries, nor propose building a virtual normalized view layer for direct use by NL2SQL. Therefore, this approach struggles to overcome the semantic gap challenge faced in the implementation of NL2SQL in enterprise databases.

[0020] Overall, current technologies are relatively passive and one-sided in terms of semantic understanding, lacking the ability to actively test and verify and comprehensively model semantics like human experts. This is precisely the problem that this invention aims to solve.

[0021] To address the aforementioned technical issues, this application proposes an enterprise-level database field semantic verification method and system based on active probes. The method includes: determining the data prototype corresponding to the field value of a target field in the database; determining the target name semantics of the target field; determining multiple candidate field value semantics for the target field based on the data prototype, target name semantics, and context information corresponding to the target field; determining a first observable difference among the multiple candidate field value semantics; determining a first probe structured query statement from a probe library based on the first observable difference, context information, and data prototype; and determining the target field value semantics from the multiple candidate field value semantics based on the query result of the first probe structured query statement. This application's embodiments reduce the risk of semantic misjudgment through active probe query verification, and by using the target name semantics and target field value semantics of the target field, it enables large language models to understand the database content, thereby improving the accuracy of large language models in performing real-world complex tasks.

[0022] The following description, in conjunction with the accompanying drawings, illustrates an enterprise-level database field semantic verification method based on an active probe, according to an embodiment of this application.

[0023] like Figure 1 As shown, the method includes the following steps: S101. Determine the data prototype corresponding to the field value of the target field in the database.

[0024] The target field can be any field from all fields in the database. The target field can be a table field, a column field, etc.

[0025] In some implementations, data prototypes are used to reflect the broad semantic attributes of fields, such as: Identifier categories: such as primary key IDs, user IDs, etc., which typically have characteristics such as high cardinality entropy and uniform distribution. Enumeration categories: such as status codes and type fields, which typically have low cardinality entropy, discrete values, and obvious small sets. Quantitative measures: such as amounts and scores, which are typically numeric types and have a specific skewness distribution. Text descriptions: such as names and addresses, which are typically string types with high cardinality entropy and embedding centroids pointing to specific entity categories.

[0026] In some embodiments, the task of a reconnaissance agent can be to perform data profiling on the tables and columns of the database, extracting basic statistical and pattern information to form a "fingerprint" feature for each field. Unlike traditional data profiling, which only counts maximum, minimum, and null values, the reconnaissance agent focuses on extracting deeper features that reflect semantics, constructing a semantic fingerprint vector. Table 1 provides design examples of semantic fingerprint feature vectors in embodiments of this invention: Table 1: Examples of semantic fingerprint features for data columns

[0027] In some embodiments, the reconnaissance agent performs the fingerprint extraction process described above for each table, calculating a set of feature vectors for each field. These vectors are then fed into a pre-trained meta-classification model. This model can automatically classify fields into several predefined data prototypes based on the fingerprint vectors.

[0028] By interpreting the fingerprint using a meta-classifier, the scout agent can initially determine the possible semantic category of each field. This provides guidance for subsequent, more refined reasoning. For example, if a field is identified as an "identifier," its relationship with other tables may be considered; if it is identified as an "enumeration," the business status represented by its different values ​​needs to be examined.

[0029] The scout agent's fingerprint calculation process can also be considered a form of proactive probing, as certain features (such as value distribution) may involve executing SQL aggregation queries to obtain statistical information. These queries are low-load and will not significantly impact the production system. In practice, sampling of large tables or the use of database metadata (such as index statistics) can optimize fingerprint extraction efficiency.

[0030] In some embodiments, this application provides a schematic diagram of the process for determining a data prototype. For example... Figure 2 As shown, firstly, original fields are sampled from the database. Then, semantic fingerprint features are extracted from the original fields through feature extraction. These semantic fingerprint features include cardinality entropy, format mask distribution, numerical distribution skewness, word embedding center, and null value correlation. Based on the semantic fingerprint features of a certain original field, a corresponding semantic fingerprint vector is generated. Then, data prototypes corresponding to the semantic fingerprint vectors are generated through each classifier, such as identifiers, numerical measures, and enumeration categories.

[0031] S102. Determine the semantics of the target name of the target field.

[0032] S103. Based on the data prototype, target name semantics, and context information corresponding to the target field, determine multiple candidate semantics for the field values ​​of the target field; S104. Determine the first observable difference in the semantics of multiple field value candidate samples; S105. Determine the first probe structured query statement from the probe library based on the first observable difference, context information, and data prototype; S106. Determine the target field value semantics from multiple candidate field value semantics based on the query results of the first probe structured query statement.

[0033] In some embodiments, the field name of the target field may be an abbreviation, the first letter of the pinyin, or a field name with a meaningless number. The semantic meaning of the target name of the target field can be determined based on the abbreviation, the first letter of the pinyin, or the field name with a meaningless number. For example, the semantic meaning of the target name of the target field cjsj is determined to be the creation time.

[0034] In some implementations, in addition to field names that use abbreviations, initials of pinyin, or meaningless numbers, the database may also contain field values ​​with ambiguous semantics. For example, some databases may have multiple tables that contain the "status" field, but with different business semantics.

[0035] To solve the above problems, it is also necessary to determine the semantics of the ambiguous field values.

[0036] In some embodiments, after determining the target name semantics of the target field, the data prototype and context information of the target field are obtained, and multiple candidate semantics of field values ​​of the target field are determined based on the data prototype, context information and target name semantics.

[0037] In some embodiments, after determining the data prototype and the target name semantics, multiple candidate semantics of the target field value can be determined based on the context information and the target name semantics. For example, if the data prototype is determined to be an "enumeration / discrete code" data prototype and the target name semantics is a user type, the user type can be determined to be divided into three types: administrator / ordinary user / visitor based on the context information.

[0038] After identifying multiple candidate semantics for field values, a first observable difference between the multiple candidate semantics for field values ​​can be determined. This first observable difference can be a semantic difference between the multiple candidate semantics for field values, such as the different content accessible to administrators / regular users / visitors.

[0039] Furthermore, based on the first observable difference, contextual information, and data prototype, a first probe structured query statement is determined from the probe library; the semantics of the target field value are determined based on the query results of the first probe structured query statement. In some embodiments, diagnostic queries with strong discriminative power and low load are selected from a predefined probe template library for verification. Probes typically include: grouping and statistically analyzing enumerated values ​​to confirm the value range and distribution pattern and detect outliers (e.g., counting for dirty values ​​or extremely low-frequency values ​​other than {1,2,3}); statistically analyzing the correlation between enumerated values ​​and user behavior or permission strength (e.g., calculating the number of corresponding permission table records, accessible resources, or operation log strength by grouping by type; if a certain type has a significantly higher number of permissions than others, it is more likely to be an "administrator / advanced role"); verifying the co-occurrence relationship between enumerated values ​​and business stage or status fields (e.g., for the order class status field, grouping by status to count the proportion of non-empty pay_time or the occurrence rate of related records in the logistics table, thereby inferring that certain status codes are more likely to correspond to stages such as "paid / shipped"); and detecting the consistency of enumerated values ​​with other fields to extract business rules (e.g., observing whether close_time is almost always non-empty under a certain status code, thereby forming a "status → field constraint" rule). The system falsifies and confirms candidate semantics based on the statistical differences returned by the probes, and finally determines the mapping relationship of "enumeration value → business meaning". The system writes the mapping, probe evidence summary and confidence into the dynamic semantic knowledge graph to form a traceable semantic conclusion.

[0040] In some embodiments, in addition to enumerated fields, identifier / key fields can trigger probes for uniqueness, dependency inclusion, and join rationality; timestamp fields can trigger probes for null value patterns, sequential constraints, and monotonicity / trends; and metric fields can trigger probes for additivity, consistency, and outliers, thereby forming a set of scalable enterprise-level database self-understanding and semantic governance methods.

[0041] In some embodiments, to facilitate understanding of the process of determining the semantics of the target field value, this application also provides a flowchart illustrating the process of determining the semantics of the target field value.

[0042] like Figure 3 As shown, the method includes the following steps: S301. Based on the data prototype, target name semantics, and context information corresponding to the target field, determine multiple candidate semantics for the target field's field values.

[0043] S302, Determine the first observable difference in the semantics of multiple field value candidate pairs.

[0044] S303. Determine the first probe structured query statement from the probe library based on the first observable difference, context information, and data prototype.

[0045] S304. Determine the target field value semantics from multiple candidate field value semantics based on the query results of the first probe structured query statement.

[0046] This application proposes an enterprise-level database field semantic verification method and system based on active probes, including: determining the data prototype corresponding to the field value of a target field in the database; determining the target name semantics of the target field; determining multiple candidate field value semantics of the target field based on the data prototype, the target name semantics, and the context information corresponding to the target field; determining a first observable difference among the multiple candidate field value semantics; determining a first probe structured query statement from a probe library based on the first observable difference, context information, and data prototype; and determining the target field value semantics from the multiple candidate field value semantics based on the query result of the first probe structured query statement. The embodiments of this application reduce the risk of semantic misjudgment through active probe query verification, and improve the accuracy of large language models in performing real-world complex tasks by enabling large language models to understand the content of the database through the target name semantics and target field value semantics of the target field.

[0047] In some embodiments, determining the target name semantics of the target field includes: if the field name of the target field is an irregular field name, determining multiple candidate field name semantics based on the field name; determining a second probe structured query statement from the probe library based on the second observable differences corresponding to the multiple candidate field name semantics and context information; and determining the target name semantics from the multiple candidate field name semantics based on the query results of the second probe structured query statement.

[0048] After determining the data prototype of the target field, determine whether the field name of the target field is an irregular field.

[0049] In some embodiments, it can be determined whether the field name of the target field is an irregular field by means of regular expression detection or SQL reserved word detection.

[0050] When the field name of the target field is determined to be a non-regular field, multiple candidate semantics for the field name corresponding to the target field can be determined.

[0051] In some embodiments, the methods for determining the semantic meaning of multiple candidate field names corresponding to the target field may include: The system generates candidate words using a pinyin dictionary and abbreviation rules (matching initials / finals and common abbreviation patterns), and improves coverage by combining it with a database of common business terms. Search-based candidates: Retrieve candidates from the enterprise thesaurus / domain knowledge base / historical table field database by pinyin similarity, edit distance, and embedding similarity.

[0052] Knowledge graph-driven candidate: If a similar field has already been confirmed in the same library / domain, candidates can be directly recalled from the knowledge graph by "similar pinyin form + consistent prototype".

[0053] LLM / Sequence Model Candidate Generation: Using column names and context (fields in the same table, sample value summaries, prototypes) as prompts, the model generates candidate terms, and then proceeds to semantic anchoring and validation.

[0054] External publicly available resources for assistance: publicly available abbreviation dictionaries, industry knowledge bases to aid decision-making, etc.

[0055] In some embodiments, it is assumed that the field name of the target field is cjsj, which can be combined with the field name to obtain two possible pinyin expansions: "Creation Time (Chuang Jian Shi Jian)" and "Transaction Time (Cheng Jiao Shi Jian)".

[0056] The second observable difference can be the semantic difference between multiple candidate field names. For example, the creation time can be the time bound to the order, that is, the existence of an order will definitely have a creation time, but the existence of an order will not necessarily have a transaction time.

[0057] After determining the second observable difference, fields that can be used to verify the semantics of the multiple target name candidates can be identified from the context information. For example, when verifying the creation time and transaction time, the context information contains "dd_id" (order ID) and "kh_id" (customer ID). Furthermore, the first probe structured query statement can be determined from the probe library to obtain the second probe structured query statement that is consistent with the second observable difference and the context information.

[0058] In some embodiments, a second probe structured query statement can be obtained to calculate the Pearson correlation coefficient between "dd_id" and "cjsj": SELECT CORR(dd_id", cjsj) FROM TB_JY_2024. If the correlation coefficient is very close to 1, it indicates that "cjsj" and the order ID are strongly positively correlated, meaning that if an order ID exists, "cjsj" will definitely exist. This is consistent with the relationship between creation time and "dd_id" mentioned above, so the target name semantics of "cjsj" can be determined to be the creation time.

[0059] In some embodiments, determining the target name semantics of a target field includes: if the field name of the target field is an irregular field name, determining multiple candidate field name semantics based on the field name; determining the confidence level corresponding to each of the multiple candidate field name semantics based on the data prototype and context information; if there are multiple candidate target name semantics with confidence levels greater than a first preset confidence threshold, determining a third probe structured query statement from the probe library based on the third observable differences corresponding to the multiple candidate target name semantics and context information; and determining the target name semantics from the multiple candidate target name semantics based on the query results of the third probe structured query statement.

[0060] In some embodiments, a data prototype of the target field can be obtained to determine whether the semantics of multiple candidate field names conform to the data prototype. For example, it can be determined that the data prototype is a floating-point number and all of them are non-negative, and that the creation time and transaction time both conform to the data prototype.

[0061] Furthermore, obtain the context information corresponding to the target field. The context information corresponding to the target field can be the context information of the target field table data. For example, it can obtain the columns of the target field table data and determine whether each column includes columns related to the candidate semantics of each field name.

[0062] In some embodiments, taking the cjsj column as an example, it is assumed that the results from the scout agent show that the data type of this column is floating-point numbers and all are non-negative, and the table also contains the fields "dd_id" (order ID) and "kh_id" (customer ID). For candidate terms: both creation time and transaction time meet the characteristic of being non-negative floating-point numbers, and are reasonable in the order scenario.

[0063] The confidence level can be determined by the degree of association between the candidate semantics of the field name and the data prototype, as well as the degree of association between the candidate semantics of the field name and the contextual information.

[0064] In some embodiments, a pre-trained language model or domain knowledge base can be used to score the degree of association between the candidate semantics of the field name and the context information, as well as the degree of association between the candidate semantics of the field name and the data prototype, to obtain two scores.

[0065] Further, based on the two scores mentioned above, determine the confidence levels corresponding to the creation time and the transaction time, respectively.

[0066] The first preset confidence threshold can be flexibly set based on the actual situation, and will not be elaborated here.

[0067] The third observable difference can be the semantic difference between multiple target name candidate semantics, and the third probe structured query statement can be determined from the probe library based on the third observable difference corresponding to multiple target name candidate semantics and context information; the target name semantics are determined from multiple target name candidate semantics based on the query results of the third probe structured query statement.

[0068] In some embodiments, to facilitate understanding of the process of determining the semantics of the target name described above, this application also provides a flowchart illustrating the process of determining the semantics of the target name.

[0069] like Figure 4 As shown, the process includes the following steps: S401. Determine whether the field name of the target field is an irregular field by using regular expression detection.

[0070] If the target field name is a non-regular field name, then execute S402 to determine multiple candidate semantics for field names based on the field name.

[0071] If the target field name is the rule field name, then execute S403 to determine the rule field name as the target name semantics.

[0072] S404. Determine the confidence level corresponding to the semantics of multiple field name candidates based on data prototypes and context information.

[0073] S405. Determine whether there are multiple target name candidate semantics with a confidence level greater than the first preset confidence threshold.

[0074] If multiple candidate semantics of field names have multiple candidate semantics of target names with a confidence level greater than the first preset confidence threshold, then execute S406 to determine the third probe structured query statement from the probe library based on the third observable differences corresponding to the multiple candidate semantics of target names and context information.

[0075] If there are no multiple target name candidate semantics with a confidence level greater than the first preset confidence threshold among multiple field name candidate semantics, then multiple field name candidate semantics are regenerated through S402.

[0076] S407. Determine the target name semantics from multiple target name candidate semantics based on the query results of the structured query statement based on the third probe.

[0077] In some embodiments, the method further includes: calculating the similarity between field values ​​of each field in the database; determining multiple target field values ​​with a similarity greater than a preset similarity threshold; calculating the inclusion degree between multiple target field values; determining multiple overlapping field values ​​with an inclusion degree greater than an inclusion degree threshold; and if the data prototypes corresponding to the multiple overlapping field values ​​are consistent, then determining the table data to which the multiple overlapping field values ​​belong as related table data.

[0078] In some implementations, modern data warehouses often do not establish physical foreign key constraints for performance optimization. When generating JOIN statements, the model can only guess based on column names, which often leads to incorrect association of data from unrelated tables, such as incorrectly associating user_id with creator_id, or missing paths that should only be joined through intermediate tables.

[0079] In some embodiments, in order to determine the degree of correlation between the data in each table, the similarity between the field values ​​of each field in the database is first calculated.

[0080] In some implementations, the Jaccard similarity for each pair of field value sets can be estimated using MinHash or Bloom filters.

[0081] When the similarity is greater than the preset similarity threshold, the corresponding field is determined as the target field value. The preset similarity threshold can be flexibly set based on the actual situation, and will not be elaborated here.

[0082] It is understandable that a similarity score greater than a preset similarity threshold does not necessarily indicate a relationship between fields. In some embodiments, after determining multiple target field values, the inclusion degree among the multiple target field values ​​can be calculated.

[0083] If the coverage of the target field values ​​corresponding to the two tables is greater than the coverage threshold, then the target field values ​​corresponding to the two tables are considered to be overlapping field values.

[0084] The threshold value can be flexibly set based on the actual situation, which will not be elaborated here.

[0085] Overlapping values ​​alone are insufficient; further verification of the candidate relationships is achieved by utilizing the data prototypes corresponding to each field value. If the data prototypes corresponding to multiple overlapping field values ​​are consistent, then the multiple overlapping field values ​​are determined to be related field values, and the table data to which the related field values ​​belong is identified as the relevant table data.

[0086] In some embodiments, the above method further includes: A knowledge graph is constructed based on the semantics of the target name, the semantics of the target field values, and related table data.

[0087] In some embodiments, after obtaining the target name semantics, target field value semantics, and related table data, it is necessary to modify the data in the original database. In order to uniformly modify the data in the original database and to better obtain the aforementioned target name semantics, target field value semantics, and related table data, a knowledge graph will be constructed based on the target name semantics, target field value semantics, and related table data.

[0088] Knowledge graphs can be implemented using graph databases or triple storage, where: Nodes represent entities, such as table entities, field entities, and value domain entities.

[0089] Edges represent relationships, including relationships between fields and relationships between table data.

[0090] Each node and edge can have attributes that record its source (e.g., the source of a semantic tag, its confidence level, whether it has been verified and supported by queries, etc.).

[0091] The semantic label is the result of the fusion of the target name semantic, the target field value semantic, and one or more related table data. For example, for the field cjsj: YYYY-MM-DD HH:MM:SS, the corresponding semantic label could be the target name semantic as transaction time, and the related table data as order_id: 22558.

[0092] In some embodiments, the knowledge graph is continuously updated. When a field in the database is updated, the semantics of the target name, the semantics of the target field value, and the related table data can be determined, and this updated content is written into the knowledge graph. Simultaneously, the content in the DSKG also provides context for the agent.

[0093] Through DSKG, this invention establishes a machine-understandable unified semantic view that encompasses not only static descriptions of fields and tables but also validated dynamic constraints and rules. This knowledge graph itself can also serve as an output of enterprise data asset management, supporting data governance.

[0094] In some embodiments, the method further includes: obtaining context information from a knowledge graph; and / or obtaining context information from data prototypes corresponding to the field values ​​of each field in the database.

[0095] In some embodiments, in addition to summarizing the semantics of target names, the semantics of target field values, and related table data, the knowledge graph can also provide contextual information for determining the semantics of target names and the semantics of target field values.

[0096] Therefore, in determining the semantics of the target name and the semantics of the target field value, the corresponding contextual information can be obtained from the knowledge graph.

[0097] In addition, contextual information can also come from data prototypes.

[0098] In some embodiments, the database can be preprocessed to obtain basic information in the database before determining the semantics of the target name, the semantics of the target field value, and the related table data.

[0099] In some implementations, the basic metadata of the database, tables, and columns (column name, type, nullability, index / primary key / foreign key information, table comments, etc.) can be read by the driver.

[0100] In some embodiments, context information can also be obtained from the basic information described above.

[0101] In some embodiments, in order to allow users to query information such as the semantics of the target name, the semantics of the target field value, and the source and reliability of the related table data, it is also possible to obtain the confidence level corresponding to the semantics of the target name and the semantics of the target field value, as well as determine the structured query statement corresponding to the semantics of the target name and the semantics of the target field value.

[0102] In some embodiments, during the process of determining the semantics of the target name and the semantics of the target field value, a first confidence level of the semantics of the target name and a second confidence level of the semantics of the target field value can also be determined.

[0103] In some embodiments, the method further includes: for target table data, obtaining the target name semantics and target field value semantics of multiple fields corresponding to the target table data, as well as at least one table data related to the target table data from a knowledge graph; renaming the irregular field names of the multiple fields to canonical names that conform to the target name semantics of the multiple fields; modifying the field values ​​corresponding to the multiple fields to Boolean fields based on the target field value semantics of the multiple fields respectively; establishing foreign key relationship information of the target table data based on at least one table data related to the target table data; and establishing an access interface for the large language model to access the canonical names, Boolean fields, and foreign key relationship information.

[0104] Understandably, in order to read the data modified from the database instead of the original data when the large model is executing a task, after determining the semantics of the target name, the semantics of the target field value, and the related table data, it is necessary to summarize the above semantics of the target name, the semantics of the target field value, and the related table data in order to improve the efficiency of modification.

[0105] Since the knowledge graph summarizes the semantics of the target name, the semantics of the target field value, and the related table data, the corresponding semantics of the target name, the semantics of the target field value, and the related table data can be directly obtained from the knowledge graph to modify the database and provide an interface for the large language model so that the large language model can directly read the modified data.

[0106] In some embodiments, after completing the data collection and knowledge extraction described above, the present invention constructs a semantically normalized representation layer on the database using logical views. The steps are as follows: View Definition: For each physical table, create a corresponding semantic view. In the view definition, rename the fields of the original table to the canonical names determined by the linguist agent. For example, create a view v_jy_2024 (or another name such as v_order_2024) from the original table TB_JY_2024, where: CREATE VIEW v_order_2024 AS SELECT dd_idAS order_id, kh_idAS customer_id, zjeAS total_amount, cjsjAS create_time, ... FROM TB_JY_2024; Assuming that the aforementioned process confirms that `cjsj` represents the creation time, then these standardized names will be used to replace the original field names in the view. The `cjsj` field will be standardized and named `create_time` for use by upper-level queries. Simultaneously, the view metadata comments will specify: "Creation Time: The time the order record was generated."

[0107] Injection Constraints and Annotations: For defined inter-table relationships, foreign key constraints can be simulated or additional explanations can be provided at the view layer based on the relevant table data. Foreign key relationship declarations can be added to views if the database supports them. For views in some databases that do not support strict constraints, this can be noted in the knowledge graph or documentation. Additionally, the system binds important business rules and field meanings as annotation metadata to views / fields. For example, the annotation for the field `account_status` is set to: "0 indicates logged out, 1 indicates active" to prompt the user. During the NL2SQL prompt construction phase, these annotations will be provided to the LLM to eliminate ambiguity. The semantic annotation for the `type` field is defined as: "User type (1=administrator, 2=regular user, 3=inactive)". In the VNL view, it can be optionally split into three boolean fields (`is_admin`, `is_active`, etc.) or retained as an enumeration with accompanying annotations, depending on the specific downstream application requirements.

[0108] Access control: The view layer can also serve as a controlled access interface, allowing enterprises to authorize queries based on the view without directly exposing the underlying tables. This improves security when using NL2SQL, preventing unrelated or sensitive tables from being accessed unintentionally.

[0109] The completed VNL layer becomes the sole entry point for the NL2SQL system to interact with the database. After the LLM model receives a user's natural language question, the system parses the question into SQL for the view layer; then, the database translates the view query to access the underlying physical tables to return the result. Because the view layer has eliminated ambiguity and completed implicit relationships to the greatest extent possible, the probability of LLM generating erroneous SQL is significantly reduced.

[0110] In some embodiments, the method further includes: enumerating the target field value semantics and annotation information of the target field value semantics corresponding to multiple fields respectively; or converting the target field value semantics corresponding to multiple fields into natural language description information.

[0111] Understandably, the modified table data can be provided not only to the large model, but also to users and the front end. Therefore, in addition to modifying the field values ​​corresponding to multiple fields to boolean fields based on the semantics of the target field values ​​corresponding to multiple fields, it is also possible to enumerate the semantics of the target field values ​​corresponding to multiple fields and the annotation information of the target field value semantics; or to convert the semantics of the target field values ​​corresponding to multiple fields into natural language description information.

[0112] In some embodiments, the above differences are described by the following examples: Assume the original database data is: user_id: 10086 type: 1 department_id: 42 The result of enumerating the semantics of the target field values ​​and the annotation information for the semantics of the target field values ​​for multiple fields is as follows: ui_view: type: annotated_enum badge: text: "Administrator" color: "#E74C3C"# Red alert indicating high privileges icon: "shield_admin.svg" actions_allowed: ["*"] # Wildcard represents full permissions Based on the semantics of the target field values ​​corresponding to multiple fields, the field values ​​corresponding to the multiple fields are modified to booleans as follows: permission_view: type: boolean_features is_admin: true is_active: true can_delete_others: true can_modify_system_config: true The semantics of the target field values ​​corresponding to multiple fields are converted into natural language description information as follows: nlp_view: type: text_description The user is a system administrator with the highest operating privileges, and the account is in a normal activated state.

[0113] To facilitate understanding of the above process, the embodiments of this application provide the following examples: Example 1: Recognition and verification of the pinyin abbreviation "cjsj": First, assuming an e-commerce transaction database contains a table TB_JY_2024 with a field named cjsj, a scout agent is introduced to determine the data prototype of this field. It is found that its value is in the format of a timestamp, "YYYY-MM-DD HH:MM:SS", and is not empty in any order record. Therefore, this fingerprint indicates that its data prototype is a time-related field.

[0114] Furthermore, the field name was determined to be an irregular field by regular expression detection or SQL reserved word detection, and multiple candidate semantics for the target field were determined. Based on the pinyin dictionary and abbreviation rules, the candidate semantics of multiple field names were determined to be "Creation Time (Chuang Jian Shi Jian)" and "Transaction Time (Cheng Jiao Shi Jian)".

[0115] In determining the semantics of multiple candidate field names, the data prototypes for both creation time and transaction time conform to time-related fields, and the context information includes the fields "dd_id" (order ID) and "kh_id" (customer ID). Based on the data prototypes and context information, the confidence levels of creation time and transaction time are both greater than the preset confidence threshold. Therefore, a structured query is required to determine the semantics of the target name.

[0116] First, we determined the first observable difference between the two candidate target names and found that the creation time can be the time bound to the order. That is, the existence of an order will definitely have a creation time, but the existence of an order will not necessarily have a transaction time.

[0117] After identifying the first observable difference, the fields "dd_id" (order ID) and "kh_id" (customer ID) that can be used to verify the semantics of the multiple target name candidates are determined from the context information. Further, the first probe structured query statement, which is related to the first observable difference and context information, can be obtained from the probe library: SELECT CORR(order_id, cjsj) FROM TB_JY_2024; This calculates the Pearson correlation coefficient between order_id and cjsj. The query result shows a correlation coefficient of 0.98 and no null values. If it's the order time, there will definitely be no null values; if it's the transaction time, null values ​​will exist. Therefore, the target name semantics of cjsj are determined to be "creation time". Furthermore, this target name semantics is written into the knowledge graph. When constructing the virtual normalization layer, the target name semantics of cjsj is obtained as "creation time". Based on this target name semantics, cjsj is modified to create_time. Furthermore, a comment "creation time: the time when the order record was generated" can be added to create_time.

[0118] Example 2, probe verification of enumeration code: A user table has a field named `Type` with values ​​in the range {1, 2, 3}, representing user categories, but there is no documentation explaining this. A typical LLM might intuitively guess that 1 = administrator (admin), 2 = regular user (user), and 3 = guest (guest), but the accuracy is unknown.

[0119] First, a scout agent is introduced to determine that the data prototype of this field value is an enumeration field (with very low cardinality and only 3 distinct values).

[0120] The target name semantics of the field are obtained as user type. Based on the context information, it is found that the three values ​​have different access permissions. Therefore, the candidate semantics of the multiple field values ​​of this field are determined to be administrator / regular user / visitor.

[0121] Further, the second observable differences in the semantics of the candidate values ​​for the aforementioned multiple fields are determined. The accessible content differs for administrators, regular users, and visitors. Based on these second observable differences, contextual information, and data prototypes, a second probe structured query statement is determined from the probe library. The probe library typically includes methods for grouping and statistically analyzing enumerated values ​​to confirm the value range and distribution pattern and detect outliers (e.g., checking for dirty values ​​or extremely low-frequency values ​​other than {1,2,3}); correlation statistics between enumerated values ​​and user behavior or permission strength (e.g., calculating the number of corresponding permission table records, accessible resources, or operation log strength by type; if a certain category has a significantly higher number of permissions than others, it is more likely to be an "administrator / advanced role"); and verification of the co-occurrence relationship between enumerated values ​​and business stage or status fields (e.g., for the order category's status field, calculating pay_time by status group). The non-empty ratio or the occurrence rate of related records in the logistics table can be used to infer that certain status codes are more likely to correspond to stages such as "paid / shipped"; and the consistency of enumeration values ​​with other fields can be checked to extract business rules (for example, observe whether close_time is almost always non-empty under a certain status code, thus forming the rule of "status → field constraint").

[0122] Further analysis using the second observable difference and contextual information revealed that the second probe's structured query statement was to perform statistical correlation between enumerated values ​​and user behavior or permission strength. The contextual information also included a permission table (Permissions), which might contain a correspondence between users and permissions. This resulted in the following second probe structured query statement: `SELECT type, COUNT(DISTINCT permission_id) FROM User JOIN User_Permissions ON User.id = User_Permissions.user_id GROUP BY type;`, which counts the number of permission types possessed by different user types.

[0123] For example, the query results show that users with type=1 have an average of 50 permissions, users with type=2 have 5, and users with type=3 have 0. From this, the system infers that the target field value for type=1 indicates an administrator (with the most permissions), the target field value for type=2 indicates a regular user, and the target field value for type=3 indicates an unverified user or a deleted user (without permissions). The system then generates the corresponding confidence scores.

[0124] The semantic annotation of the `type` field is further defined as: "User type (1=administrator, 2=regular user, 3=inactive)". This target field value semantic is then sent to the knowledge graph. When constructing the virtual normalization layer, the semantic of this target field value obtained from the knowledge graph can be either split into three boolean fields (`is_admin` (administrator), `is standard` (regular user), `is_active` (inactive), etc.) or retained as an enumeration with the annotations: 1=administrator (highest privileges), 2=regular user (moderate privileges), 3=inactive (no privileges).

[0125] In some embodiments, this application also provides a schematic diagram of a system architecture for implementing an enterprise-level database field semantic verification method based on active probes.

[0126] like Figure 5 As shown, the system includes: a scout agent, a linguist agent, a topology discovery agent, a knowledge graph, and a virtual normalization layer.

[0127] The scout agent is used to determine the data prototype corresponding to the field value of a target field in the database. A linguist agent is used to determine multiple candidate semantics of field values ​​for a target field based on data prototypes, target name semantics, and contextual information corresponding to the target field; determine the first observable difference between the multiple candidate semantics of field values; determine the first probe structured query statement from the probe library based on the first observable difference, contextual information, and data prototype; and determine the target field value semantics from the multiple candidate semantics of field values ​​based on the query results of the first probe structured query statement.

[0128] First, the scout agent retrieves fields from the database, determines the data prototype corresponding to the field value of each field, and outputs the data prototype of each field to the linguist agent, the topology discovery agent, and the knowledge graph.

[0129] If the linguist agent determines that the target field name is an irregular field name, it determines multiple candidate semantics for the field name based on the field name; it determines the confidence level of each candidate semantic for the field name based on the data prototype and the context information corresponding to the target field; if there are multiple candidate semantics for the target name with a confidence level greater than a first preset confidence threshold, it determines a first probe structured query statement from the probe library based on the first observable differences and context information corresponding to the multiple candidate semantics for the target name; and it determines the target name semantics based on the query results of the first probe structured query statement.

[0130] In addition, the linguistic agent determines multiple candidate semantics of field values ​​for the target field based on data prototypes, contextual information, and target name semantics; determines the second observable difference between the multiple candidate semantics of field values; determines the second probe structured query statement from the probe library based on the second observable difference, contextual information, and data prototype; and determines the target field value semantics based on the query results of the second probe structured query statement.

[0131] Furthermore, the linguist agent inputs the target name semantics and target field value semantics of each field into the knowledge graph.

[0132] The topology discovery agent calculates the similarity between field values ​​in the database; identifies multiple target field values ​​with a similarity greater than a preset similarity threshold; calculates the inclusion degree between multiple target field values; identifies multiple overlapping field values ​​with an inclusion degree greater than a inclusion degree threshold; if the data prototypes corresponding to multiple overlapping field values ​​are consistent, the table data to which the multiple overlapping field values ​​belong is determined to be related table data. The related table data is then input into the knowledge graph.

[0133] The system constructs a virtual normalization layer based on target name semantics, target field value semantics, and related table data: For the target table data, obtain the semantic meaning of the target name and the semantic meaning of the target field value for multiple fields corresponding to the target table data from the knowledge graph, as well as at least one table data related to the target table data; rename the irregular field names of multiple fields to canonical names that conform to the semantic meaning of the target name of multiple fields; modify the field values ​​corresponding to multiple fields to Boolean fields based on the semantic meaning of the target field value of each field; establish foreign key relationship information of the target table data based on at least one table data related to the target table data; and establish an access interface for the large language model to access the canonical name, Boolean field, and foreign key relationship information.

[0134] It should be noted that: Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0135] Similarly, it should be understood that, for the sake of brevity and to aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together in a single embodiment, figure, or description thereof. However, this disclosure should not be construed as reflecting a schematic diagram in which the claimed application requires more features than expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0136] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0137] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for semantic verification of enterprise-level database fields based on active probes, characterized in that, include: Determine the data prototype corresponding to the field value of the target field in the database. The data prototype is used to reflect the major category semantic attributes of the field. Determine the target name semantics of the target field; Based on the data prototype, the target name semantics, and the context information corresponding to the target field, multiple candidate semantics for the field values ​​of the target field are determined; Determine the first observable difference in the semantics of the candidate field values; Based on the first observable difference, the context information, and the data prototype, a first probe structured query statement is determined from the probe library; The target field value semantics are determined from the multiple candidate field value semantics based on the query results of the first probe structured query statement; Determining the target name semantics of the target field includes: If the field name of the target field is a non-regular field name, multiple candidate semantics for the field name are determined based on the field name; Based on the data prototype and the context information, determine the confidence level corresponding to the candidate semantics of the multiple field names respectively; If there are multiple target name candidate semantics with a confidence level greater than the first preset confidence threshold, a third probe structured query statement is determined from the probe library based on the third observable difference corresponding to the multiple target name candidate semantics and the context information. The target name semantics are determined from multiple target name candidate semantics based on the query results of the structured query statement of the third probe.

2. The method according to claim 1, characterized in that, Determining the target name semantics of the target field includes: If the field name of the target field is a non-regular field name, multiple candidate semantics for the field name are determined based on the field name; The second probe structured query statement is determined from the probe library based on the second observable differences corresponding to the multiple candidate semantics of field names and the context information. Based on the query results of the second probe structured query statement, the target name semantics are determined from the multiple candidate semantics of field names.

3. The method according to claim 1, characterized in that, The method further includes: Calculate the similarity between the field values ​​of each field in the database; Identify multiple target field values ​​whose similarity exceeds a preset similarity threshold; Calculate the degree of inclusion among the multiple target field values; Identify multiple overlapping field values ​​with a coverage degree greater than the coverage degree threshold; If the data prototypes corresponding to the multiple overlapping field values ​​are consistent, then the table data to which the multiple overlapping field values ​​belong is determined to be related table data.

4. The method according to claim 3, characterized in that, The method further includes: A knowledge graph is constructed based on the semantics of the target name, the semantics of the target field values, and the related table data.

5. The method according to claim 4, characterized in that, The method further includes: Obtain the context information from the knowledge graph; And / or obtain the context information from the data prototypes corresponding to the field values ​​of each field in the database.

6. The method according to claim 4, characterized in that, The method further includes: For the target table data, obtain the target name semantics and target field value semantics of multiple fields corresponding to the target table data, as well as at least one table data related to the target table data from the knowledge graph; Rename the irregular field names of the multiple fields to canonical names that conform to the semantics of the target names of the multiple fields; Based on the semantics of the target field values ​​corresponding to the multiple fields, the field values ​​corresponding to the multiple fields are modified to booleans; Establish foreign key relationship information of the target table data based on at least one table data related to the target table data; Establish an access interface so that the large language model can access the canonical name, the boolean field, and the foreign key relationship information.

7. The method according to claim 6, characterized in that, The method further includes: Enumerate the target field value semantics corresponding to the multiple fields and the annotation information of the target field value semantics; Alternatively, the semantics of the target field values ​​corresponding to the multiple fields can be converted into natural language description information.

8. An enterprise-level database field semantic verification system based on active probes, characterized in that, include: The reconnaissance agent is used to determine the data prototype corresponding to the field value of a target field in the database. The data prototype is used to reflect the major semantic attributes of the field. A linguist agent is used to determine multiple candidate semantics of field values ​​for a target field based on data prototypes, target name semantics, and contextual information corresponding to the target field. Determine the first observable difference in the semantics of the candidate field values; Based on the first observable difference, the context information, and the data prototype, a first probe structured query statement is determined from the probe library; based on the query result of the first probe structured query statement, a target field value semantic is determined from the multiple field value candidate semantics; If the linguist agent determines that the field name of the target field is an irregular field name, it determines multiple candidate semantics for the field name based on the field name; Based on the data prototype and the context information, determine the confidence level corresponding to the candidate semantics of the multiple field names respectively; If there are multiple target name candidate semantics with a confidence level greater than the first preset confidence threshold, a second probe structured query statement is determined from the probe library based on the second observable difference corresponding to the multiple target name candidate semantics and the context information. The target name semantics are determined from multiple target name candidate semantics based on the query results of the structured query statement of the second probe.

Images