A natural language intelligent interrogation method and system based on a trusted semantic core

Abstract

The application relates to a natural language intelligent query method and system based on a trusted semantic core, and belongs to the technical field of data governance. After receiving a user natural language query request, the method performs multi-round dialogue context merging, word segmentation normalization processing, extracts business original words, generates pure business semantic load, relies on a governed semantic asset knowledge base to complete semantic analysis, generates a controlled query plan instruction completely decoupled from user input, and after semantic asset validation, dimension and index level double verification, is translated into a parameterized SQL execution to obtain data results, and is finally encapsulated into a trusted data package and a natural language answer is generated and returned to the user. The scheme can guarantee the consistency and accuracy of the query results, take into account the convenience and security of interaction, and effectively improve the data asset circulation efficiency and business empowerment value.

Description

Technical Field

[0001] This application relates to the technical field of data governance, and in particular to a natural language intelligent questioning method and system based on a trusted semantic core. Background Technology

[0002] In enterprise digital operations scenarios, data retrieval systems are core tools for business personnel to obtain operational analysis data from data warehouses, BI indicator platforms, or reporting systems to support business decisions. Currently, the closest existing technologies to this invention mainly cover different technical forms, including fixed BI reports, self-service data retrieval platforms, Text2SQL systems that generate SQL from natural language, and intelligent data retrieval systems that convert natural language into intermediate query DSLs for execution. These can be broadly categorized into two types based on their implementation paths.

[0003] The first category is fixed BI reports and self-service data retrieval platforms. This type of solution typically pre-configures report directories, indicator definitions, dimension levels, filtering conditions, and time range rules. Business personnel select the corresponding report or data segment on the front-end page, and the system queries the data warehouse according to pre-set SQL, report models, or indicator models and returns the results. The query chain for this type of solution is relatively stable and controllable, suitable for repetitive daily operational report queries with fixed definitions. However, it has significant interactive limitations and capability shortcomings: on the one hand, it requires a high level of professional knowledge from users, who need to be familiar with the report directory structure, the business meaning of indicators, dimension hierarchical relationships, and filtering rules. It cannot directly handle conversational, continuously probing query needs such as "Recent equipment rental volume by region," "What about Ningbo?" "By month," or "Only the top 5." On the other hand, it is difficult to adapt to flexible analysis scenarios. When business personnel need to conduct exploratory analysis, dimension drill-down analysis, or temporary combination of indicator queries, they often still need to manually search for reports one by one, understand the meaning of fields, and even rely on the data team for data retrieval assistance. This results in low query efficiency, long response times, and fails to fully unleash the business empowerment value of data assets.

[0004] The second category consists of Text2SQL systems based on large language models, and derived Natural Language to Intermediate Query (DSL) solutions. Text2SQL systems parse user natural language questions using large language models to directly generate SQL statements, which are then submitted to the database or data warehouse for execution. This lowers the expression threshold for queries to some extent, supporting more flexible, conversational questions. However, its core risk lies in the difficulty of guaranteeing the credibility and compliance of the entire query chain: the model often relies on training experience and contextual information to guess physical table names, physical field names, table relationship paths, indicator calculation methods, filtering conditions, and time ranges, resulting in significant uncertainty in the generated results. When there are fields with the same name, indicators with the same name, multiple sets of calculation methods, dynamic adjustments to table structures, row and column level permission control, data quality alerts, or multi-tenant isolation requirements in the enterprise data warehouse, directly generating SQL cannot guarantee that the query semantics are completely consistent with the enterprise's unified governance standards. It also cannot ensure that the entire query process undergoes standardized permission verification, standard verification, logging, and full-chain traceability. This easily leads to "illusion" problems such as mismatched standards and data distortion, and fails to meet enterprise-level data security and compliance audit requirements. Summary of the Invention

[0005] To ensure consistency and accuracy of query results, and to improve the efficiency of data asset transfer and business empowerment value, this application provides a natural language intelligent query method and system based on a trusted semantic core.

[0006] Firstly, this application provides a natural language intelligent question counting method based on a trusted semantic core, employing the following technical solution: A natural language intelligent question-answering method based on a trustworthy semantic core includes: Receive natural language question requests from users; The saved historical context is queried, and the natural language question number request is merged with the historical context through multi-turn dialogue context. The merged request is then segmented and normalized, and business original words are extracted to generate pure business semantic payload. Based on the pure business semantic payload, semantic parsing is performed in the governed semantic asset knowledge base to obtain one or more semantic asset candidates pointing to the data query target; Based on the semantic asset candidates, a controlled query plan instruction is dynamically generated. The controlled query plan instruction is an intermediate representation that is completely decoupled from user input and maintained by the system itself. It is used to encapsulate the data source, indicator mapping, filtering conditions, business time range and return format of the query. The controlled query plan instruction is parsed, and its effectiveness status is verified at the instruction level based on the governed semantic assets. After the instruction-level effectiveness status verification passes, the controlled query plan instruction is translated into at least one parameterized SQL statement. The effectiveness status of the at least one parameterized SQL statement is verified at the dimension level and the indicator level. After the verification passes, the at least one parameterized SQL statement is executed to obtain the data results. Based on the data results, combined with the managed semantic assets and business rules, an encapsulated trusted data packet is generated, and an answer is generated based on the trusted data packet and returned to the user.

[0007] By adopting the above technical solution, this method transforms users' colloquial, fragmented, and ellipsis-laden natural language question requests into pure business semantic payloads through multi-turn dialogue context merging and word segmentation normalization. It effectively removes redundant interjections, invalid expressions, and ambiguous contexts, accurately extracts original business words, and completes semantic matching and candidate recall in conjunction with a standardized semantic asset knowledge base that has been governed. This overcomes the limitations of false recall and missed recall in traditional keyword matching modes. Even in complex interaction scenarios such as fuzzy questions and multiple rounds of follow-up questions, it can accurately identify the user's true question intent, lower the threshold for users to obtain data, and allow business personnel to efficiently obtain target data without mastering professional technical terms and SQL syntax. Building upon this foundation, a controlled query plan instruction, completely decoupled from user input, is introduced as an intermediate representation. This instruction is autonomously maintained and generates all query logic, completely isolating user natural language input from the underlying data query execution at the architectural level. This not only blocks malicious input attack paths such as SQL injection and unauthorized queries at the source but also shields the system from the heterogeneity of multiple data sources and the disparity in data definitions. Furthermore, it decouples the semantic parsing layer from the data execution layer, reducing system iteration and maintenance costs. During query execution, a dual verification mechanism—semantic asset validity verification and dimension / metric-level validity verification—ensures that the final executed query statement fully matches the currently effective business data rules. This eliminates the output of dirty data and incorrectly defined data from the execution source, guaranteeing the consistency and accuracy of query results. Simultaneously, the parameterized SQL generation method further strengthens the security and compliance of data queries. In the output phase, the raw data results are encapsulated based on the governed semantic assets and preset business rules to form standardized, trustworthy data packets, which are then converted into natural language responses and returned to the user. This process preserves traceable information such as data definitions and sources, and automatically converts technical data into business-oriented expressions. Users can obtain accurate data results and clearly understand the corresponding business meanings. Simultaneously, the entire process is driven by unified, governed semantic assets, ensuring that data requests from different users, in different scenarios, and at different rounds adhere to the same set of business definitions, resolving the issue of inconsistent definitions for the same data in traditional data query scenarios. In summary, this method, with trusted semantics as its core, constructs a complete closed loop from semantic input, parsing, plan generation, verification execution to trusted output. It balances the convenience of natural language interaction with the security, accuracy, and controllability of enterprise-level data applications, improving the efficiency of data asset circulation and the value of business empowerment.

[0008] Optionally, the natural language intelligent question counting method is executed collaboratively between a question counting orchestration layer and a trusted core layer that are isolated from each other; wherein, at a specific stage of semantic parsing, the two layers support parallel processing and result aggregation; The question number orchestration layer performs the steps of receiving the natural language question number request, merging the multi-turn dialogue context, and extracting business primitives, and transmits the generated pure business semantic payload to the trusted core layer. The trusted core layer performs the steps of semantic parsing, generating the controlled query plan instruction, parsing and verifying the controlled query plan instruction, translating and verifying the parameterized SQL, and executing the parameterized SQL to obtain data results; wherein, the physical table name, physical field name, physical table join conditions, and database connection information are encapsulated within the trusted core layer, and the parameterized SQL is independently compiled and generated by the trusted core layer and is not passed through to the query orchestration layer. The question number orchestration layer receives the trusted data packets returned by the trusted core layer and interprets and visualizes the trusted data packets.

[0009] By adopting the above technical solution and constructing a two-layer architecture consisting of an isolated question orchestration layer and a trusted core layer, with layered decoupling and boundary control as the core design principles, the system not only ensures the flexibility of natural language question interaction but also further strengthens the security protection capabilities of core data assets and the strength of trusted control across the entire chain, thereby improving the robustness, maintainability, and compliance adaptability of the system architecture. Furthermore, the two-layer isolated architecture reduces system operation and maintenance and expansion costs. Data access control, semantic asset governance, data source access, and definition adjustments can all be completed uniformly within the trusted core layer without requiring simultaneous modifications to the front-end orchestration layer. Adding new question channels or optimizing the interactive experience only requires interfacing with the question orchestration layer, without impacting the data security and stable operation of the trusted core layer, thus achieving a balance between front-end interactive flexibility and back-end data security.

[0010] Optionally, the step of semantic parsing in the governed semantic asset knowledge base specifically includes the following steps executed in parallel by the question number orchestration layer and the trusted core layer: The question number orchestration layer initiates a recall request to the managed semantic asset knowledge base based on the pure business semantic payload. The semantic asset knowledge base stores semantic slices obtained by slicing the de-identified business semantic content according to asset type, length or semantic field block. Each semantic slice includes a topic domain, indicator definition, dimension definition, time rule and query mode. The trusted core layer performs deterministic candidate parsing on the pure business semantic payload, and returns a structured parsing result that includes indicator candidates, dimension candidates, rule hit status, and missing slots; wherein, the deterministic candidate parsing includes alias exact matching, name inclusion matching, and semantic similarity matching based on a preset vector model; When the vectorization service or vector database is unavailable, the semantic asset knowledge base automatically degrades to a combined retrieval mode based on local inverted index or local exact match to ensure that the question-and-data link still provides basic query capabilities in the service degradation state. By summing the semantic slices returned by the semantic asset knowledge base and the structured parsing results returned by the trusted core layer, one or more semantic asset candidates pointing to the data query target are obtained.

[0011] By adopting the above technical solutions, the semantic parsing link is optimized simultaneously from three dimensions: parallel computing power utilization, refined asset management, and fault tolerance backup. Without breaking the security control boundary, the parsing efficiency, recognition accuracy, and service stability are triplely improved, providing high-performance and highly reliable semantic parsing support for the natural language query system with trusted semantic core.

[0012] Optionally, after obtaining the semantic asset candidates and before generating the controlled query plan instruction, an anti-illusion forced clarification interception step is also included: Read the comprehensive matching score in the structured parsing results. When the highest comprehensive matching score of the candidate indicator is lower than the preset lower threshold, it is determined to be semantic ambiguity; when the difference between the comprehensive matching scores of the highest candidate and the second highest candidate is less than the preset difference threshold, it is also determined to be semantic ambiguity. When the same business term is mapped to multiple governance metrics with different calculation methods, or when the replacement and appending strategies for the same filtering dimension field cannot be determined when multiple rounds of dialogue context are merged, it is identified as a slot conflict, and the corresponding field is marked as pending clarification. When the semantic ambiguity or slot conflict occurs, the trusted core layer suspends the current query process, intercepts the generation of the controlled query plan instruction, and returns a structured clarification question containing candidate options to the question number orchestration layer, prohibiting the question number orchestration layer from guessing metrics, dimensions, or entities to complete the semantics.

[0013] By adopting the above technical solutions, the anti-illusion forced clarification interception mechanism is a key risk control link in the core architecture of trusted semantics. Through rule-based and strongly constrained process control, trusted control is integrated into the entire process of intent recognition, and a question control system that "does not bypass ambiguity, does not default on conflicts, and does not produce illusions" is constructed, providing a solid accuracy guarantee for enterprise-level question scenarios with high trust requirements.

[0014] Optionally, the step of dynamically generating controlled query plan instructions based on semantic asset candidates specifically includes a controlled construction step based on a whitelist patch merging mechanism: Convert the semantic asset candidates and the assets recalled by the semantic asset knowledge base into restricted patches; The restricted patch is scanned for fields, and only whitelisted fields containing subject domain scope, business node, edge, output format, guardrail and business query semantic fields are allowed to be written into the controlled query plan instruction; physical execution fields containing structured query language text, data source identifier, physical table name, physical column name, physical join condition or permission filtering condition are explicitly rejected. When merging multiple restricted patches, if the same field path is written with different values ​​by different restricted patches and is not declared as append mode, it is determined that the same path is mutually exclusive, the merge is rejected and a clarification request is returned.

[0015] By adopting the above technical solutions, the construction mode of whitelist access control + patching standardization merging + conflict mutual exclusion verification ensures that the generation of controlled query plan instructions is under the rigid rule control that is predictable, constrained, and traceable throughout the entire process. There is no escape path outside the rules. This not only ensures the business purity and security independence of the intermediate representation, but also improves the stability and consistency of query plan generation through standardized merging rules. It provides a standardized and reliable input basis for the subsequent SQL translation and data execution stages. It is a key trusted control node in the entire trusted query system that connects semantic parsing and data execution.

[0016] Optionally, the controlled query plan instruction includes a topology structure composed of nodes and edges, and after generating the controlled query plan instruction, it further includes a node topology dependency verification step: The plan type in the controlled query plan instruction is read, and corresponding topology validity checks are performed for different plan types, including: when the plan type is parallel, checking that there is no data dependency between nodes; when the plan type is sequential or directed acyclic graph, checking the validity of field references of nodes; when the plan type is branching, checking whether the condition reference fields of branch nodes are bound in the declaration fields of upstream nodes; when the plan type is iterative, checking whether the drill-down path, selection rules, and stopping conditions of iterative nodes come from enabled semantic asset configurations. If the verification fails, the query number arrangement layer will refuse to allow itself to perform a loop query or jump query, and will block the subsequent translation process.

[0017] By adopting the above technical solution, this topology dependency verification mechanism is an important component of the trusted query plan management system. Together with the pre-emptive whitelist patch field access verification and anti-illusion ambiguity interception, it forms a progressive multi-dimensional verification chain. It comprehensively checks the controlled query plan from three dimensions: semantic accuracy, field compliance, and structural legality, achieving full-dimensional trusted control of the query plan from content to structure. At the same time, while strictly adhering to the bottom line of control, this mechanism does not restrict the expressive power of the topology query plan. Instead, it ensures the stable and reliable implementation of complex query capabilities such as branching and iteration through standardized verification rules. This allows the system to support richer advanced business analysis query requirements in a secure and controllable manner, achieving an organic unity between functional flexibility and trusted security.

[0018] Optionally, the controlled query plan instruction is parsed, and based on the governed semantic assets and the verification of the effectiveness status of the semantic assets, the controlled query plan instruction is translated into at least one parameterized SQL statement. The effectiveness status of the at least one parameterized SQL statement is then verified at both the dimension and indicator levels. After successful verification, the at least one parameterized SQL statement is executed to obtain the data result. This process specifically includes a two-stage trusted execution step. In the first phase, the trusted core layer parses the controlled query plan instruction and performs mode verification, topic domain verification, dimension compatibility verification, time range verification, row and column level permission verification, and instruction level compliance verification on the controlled query plan instruction and the effective status of the semantic assets contained therein, based on the governed semantic assets. At the same time, it injects controlled permission filtering conditions into the controlled query plan instruction according to the current user's permissions. In the second stage, the trusted core layer translates and compiles the controlled query plan instruction after injecting controlled permission filtering conditions into at least one parameterized SQL using placeholders and parameter binding; then, it performs dimensional and metric-level validity status verification on the generated parameterized SQL; it rejects SQL fragments concatenated by the application layer and pushes the parameterized SQL that passes the verification into the execution queue for execution to obtain the data results; The trusted core layer encapsulates metadata, including data rows, indicator definitions, time ranges, data source versions, permission ranges, quality prompts, and cross-version segmentation marker fields, into a trusted data packet and returns it to the question data orchestration layer.

[0019] By adopting the above technical solutions, the two-stage trusted execution mechanism is the core implementation carrier of the trusted semantic core architecture at the execution layer. Together with the front-end anti-illusion clarification interception, whitelist patch merging, and node topology dependency verification, it constitutes a multi-layered trusted control system covering the entire chain of semantics, planning, structure, and execution. Each layer of verification performs its own function and progresses layer by layer. It not only ensures data security and credibility through closed-loop control of the entire chain, but also ensures the maintainability and scalability of the system through standardized execution processes and encapsulated outputs. It can fully adapt to enterprise-level data application scenarios with strong supervision and high credibility requirements.

[0020] Optionally, before generating the controlled query plan instruction after the anti-hallucination forced clarification interception step determines that the semantics are unique and no suspension is triggered, a temporal version interleaving segmentation step is further included: Obtain the implicit time range of facts in the natural language question count request; For each semantic asset in the semantic asset candidate, the registered temporal version information is read, wherein the temporal version information includes the effective start time, the effective end time, and the version identifier; The factual time range and the effective time range of multiple versions of each semantic asset are interleaved on the time axis to generate a versioned semantic asset list aligned by time segments, such that each entry in the versioned semantic asset list contains a non-overlapping time segment range and the version identifier corresponding to that time segment range. The versioned semantic asset list is recorded in the controlled query plan instruction as a segmented query plan data structure. The segmented query plan contains at least two time segments and version identifiers and definition texts corresponding to each time segment. Finally, when the parameterized SQL is generated, each time segment is independently translated into a subquery with a version identifier, and a version definition field is attached to the returned result data set.

[0021] By adopting the above technical solutions, the temporal version interleaving segmentation mechanism is an important capability extension of the trusted semantic core system for complex enterprise business scenarios. It fills the gap in the capability of traditional natural language query technology in temporal consistency control. Without sacrificing the convenience of interaction, it realizes automatic alignment of the query scope across periods and full temporal traceability, allowing natural language query to better adapt to the real environment of dynamic evolution of enterprise business.

[0022] Optionally, before generating a response based on the trusted data packet, the method further includes a confidence assessment and anomaly interception step based on multi-dimensional state linkage: A lightweight statistical distribution model is pre-built for each commonly used query pattern or semantic asset combination. The statistical distribution model includes expected value range, standard deviation and typical order of magnitude information, and is dynamically updated by historical valid query results. The data features in the trusted data packet are matched with the corresponding statistical distribution model, and the anomaly degree of the result is calculated; When the abnormality of the result exceeds a preset threshold, it is determined to be a low-confidence result, enters an active avoidance state, intercepts the direct output of the trusted data packet, triggers intent drift state assessment, and reads the cross-version segmentation marker field in the trusted data packet to determine whether there is a cross-version segmentation record in this query; intent drift is used to measure the continuity of the user's query intent in multi-turn dialogue; If the query finds that the intent drift status is severely drifted or that there are cross-version segmentation records, then the identifier corresponding to the change in the caliber version or the switch of the analysis topic will be written first in the speculative reason field of the generated structured confidence feed message. The structured confidence feed message will be returned to the user for confirmation, and the statistical distribution model will be updated according to the user's feedback data.

[0023] By adopting the above technical solutions, the confidence assessment and anomaly interception mechanism are key reinforcements to the core architecture of trusted semantics on the output side. They are interconnected and complementary with the front-end anti-illusion forced clarification, whitelist patch merging and management, node topology dependency verification, and two-stage trusted execution verification, and together they build a full-link, multi-level trusted protection system covering semantic input, plan generation, logic verification, data execution and result output. This deepens "trustworthiness" from process compliance to result rationality, making the output results of natural language query not only logically compliant, but also in line with business common sense and statistical laws, thereby improving the reliability, fault tolerance and business value of enterprise-level query systems.

[0024] Secondly, this application provides a natural language intelligent question-and-answer system based on a trusted semantic core, employing the following technical solution: A natural language intelligent question counting system based on a trusted semantic core, physically and logically separated into a question counting arrangement layer and a trusted core layer, comprising: The input interaction module deployed in the question orchestration layer is used to receive natural language question requests input by the user; The intelligent agent orchestration module deployed in the question number orchestration layer is used to query the saved historical context and merge the natural language question number request with the historical context through a multi-turn dialogue context. The semantic processing module deployed in the question number orchestration layer is used to perform word segmentation and normalization on the merged requests, extract business original words, and generate pure business semantic payloads. The knowledge governance module deployed in the question number orchestration layer contains a governed semantic asset knowledge base, which is used to initiate a recall request to the semantic asset knowledge base based on the pure business semantic payload to obtain semantic slices; The semantic parsing module deployed in the trusted core layer is used to perform deterministic candidate parsing on the pure business semantic payload, return the structured parsing result, and converge with the semantic slice to obtain semantic asset candidates; The domain-specific language construction module deployed in the question number orchestration layer is used to dynamically generate controlled query plan instructions based on the semantic asset candidates. The controlled query plan instructions are an intermediate representation that is completely decoupled from user input and maintained by the system itself, used to encapsulate the query data source, indicator mapping, filtering conditions, business time range and return format. The trusted execution module, deployed in the trusted core layer, is used to parse the controlled query plan instruction, translate the controlled query plan instruction into at least one parameterized SQL based on the governed semantic assets and the verification of the effective status of the semantic assets, and perform dimensional and metric-level effective status verification on the at least one parameterized SQL. After the verification passes, the at least one parameterized SQL is executed to obtain data results; and based on the data results, combined with the governed semantic assets and business rules, an encapsulated trusted data package is generated. The result expression module, deployed in the question number orchestration layer, is used to generate an answer based on the trusted data packet and return it to the user.

[0025] In summary, this application includes at least one of the following beneficial technical effects: 1. Improve the accuracy of intent recognition and user interaction convenience of natural language question counting: By merging multi-turn dialogue contexts and extracting pure business original words through word segmentation and normalization, and combining the semantic asset knowledge base of standardized governance to complete semantic matching and recall, it breaks through the limitations of false recall and missed recall of traditional keyword matching mode. It can accurately identify the user's true questioning intent in complex scenarios such as fuzzy questions and multi-turn follow-up questions; at the same time, it lowers the data acquisition threshold, and business personnel can efficiently obtain target data without mastering SQL syntax and professional technical terms.

[0026] 2. Construct a two-layer isolated security architecture to comprehensively enhance data security compliance capabilities: Adopt an architecture design that isolates the query orchestration layer and the trusted core layer, enclosing all sensitive information such as physical table names, fields, connection conditions, and database credentials within the trusted core layer. At the same time, a controlled query plan instruction that is completely decoupled from user input is introduced as an intermediate representation. Combined with a parameterized SQL compilation mechanism, this completely blocks attack paths such as SQL injection and unauthorized queries from the architectural level, forming a deep security defense system that can fully adapt to the data security compliance requirements of highly regulated scenarios such as finance and government.

[0027] 3. End-to-end multi-level trust management ensures data consistency and result accuracy: Construct a multi-level verification system covering the entire chain of semantic parsing, plan generation, and SQL execution: Pre-emptive anti-illusion forced clarification intercepts semantic ambiguity and slot conflicts; mid-level whitelist patch management and topology dependency verification standardize the legality of query plans; post-level two-stage effective verification verifies layer by layer from the instruction level to the dimension indicator level. Driven by unified governance semantic assets throughout the process, it eliminates dirty data and incorrect data output from the execution source, solves the problem of inconsistent definitions of the same data in traditional data queries, and ensures the consistency of data query results and business trustworthiness across scenarios and rounds.

[0028] 4. Deeply adapts to complex enterprise-level business scenarios, comprehensively improving system robustness and result reliability: Provides multi-dimensional capability support for complex enterprise business environments: Ensures high service availability through dual-layer parallel semantic parsing and vector service fault automatic degradation mechanism; Automatically aligns the caliber versions of cross-period queries through temporal version interleaving segmentation mechanism to adapt to the needs of dynamic iteration of business indicator calibers; Performs bottom-line verification of the business rationality of output results through multi-dimensional state linkage confidence assessment and anomaly interception mechanism, extending trust management from "process compliance" to "result rationality", comprehensively improving the system's fault tolerance capability and business acceptance value.

[0029] 5. Achieve layered decoupling of the data chain, reducing system expansion and maintenance costs: The controlled query plan instruction decouples the semantic parsing layer from the data execution layer, and the two-layer isolation architecture separates the responsibilities of front-end interaction capabilities from back-end data capabilities; semantic asset governance, data source access, caliber adjustment, and access control can all be completed uniformly in the trusted core layer. Adding new query channels and optimizing the interactive experience only requires connecting to the front-end orchestration layer without modifying the core data chain, thus reducing the cost of system iteration expansion and long-term maintenance. Attached Figure Description

[0030] Figure 1 This is a first flowchart of an embodiment of the method of this application; Figure 2 This is a second flowchart of an embodiment of the method of this application; Figure 3 This is a third flowchart of an embodiment of the method of this application; Figure 4 This is the fourth flowchart of an embodiment of the method of this application. Detailed Implementation

[0031] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-4 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0032] The first embodiment of this application discloses a natural language intelligent question counting method based on a trusted semantic core. The natural language intelligent question counting method operates collaboratively between a question counting orchestration layer and a trusted core layer, which are typically isolated from each other. During specific stages such as semantic parsing, the two layers support parallel processing and result aggregation. The overall process uses a standardized interface between the orchestration layer and the core layer for data exchange and state transitions. The question counting orchestration layer performs steps such as receiving natural language question counting requests, merging multi-turn dialogue contexts, extracting business primitives, and dynamically generating controlled query plan instructions. It then transmits the generated pure business semantic payload and controlled query plan instructions to the trusted core layer. The trusted core layer performs the steps of semantic parsing, parsing and verifying the controlled query plan instruction, translating and verifying the parameterized SQL, and executing the parameterized SQL to obtain data results. Among them, the physical table name, physical field name, physical table join conditions, and database connection information are encapsulated inside the trusted core layer. The parameterized SQL is independently compiled and generated by the trusted core layer and is not passed through to the query orchestration layer. The question number orchestration layer receives trusted data packets returned by the trusted core layer and interprets and visualizes these trusted data packets.

[0033] Specifically, this solution is implemented based on a two-layer isolation architecture of the AskBI orchestration layer and the trusted core layer. The AskBI orchestration layer is a custom Agent orchestration layer for AskBI, which is developed by default based on the LangGraph open-source state graph orchestration framework. It defines standard nodes and state transition paths such as request reception, context loading, original word extraction, parallel recall parsing, clarification processing, DSL construction, core calls, result expression, and context saving. It supports exception branch handling and state persistence. In other deployment scenarios, it can also be replaced with a self-developed state graph engine. As long as the same node orchestration, state transmission, exception branching, and context saving capabilities are achieved, the consistency of the overall process can be guaranteed. The core two-layer isolation and trusted execution logic are not affected by the choice of orchestration framework. The trusted core layer, namely AskBICore, is deployed independently and is fully responsible for semantic mapping, plan verification, SQL compilation, access control, and data execution. The two layers only interact through standardized business semantic interfaces. Physical table names, physical field names, table join conditions, and database connection information are completely closed inside the trusted core layer and are never transparent to the AskBI orchestration layer. Although this embodiment uses LangGraph and AskBICore as examples for illustration, those skilled in the art will know that the core technical features of this application do not depend on a specific framework, and any architecture that can achieve the same node orchestration and state isolation falls within the protection scope of this invention.

[0034] Reference Figure 1 The natural language intelligent question-answering method also includes S110-S160: S110, receives natural language question requests input by the user; S120: Query the saved historical context, merge the natural language query request with the historical context through multi-turn dialogue context, perform word segmentation and normalization on the merged request, extract business original words, and generate pure business semantic payload. S130, based on pure business semantic payload, performs semantic parsing in the governed semantic asset knowledge base to obtain one or more semantic asset candidates pointing to the data query target; S140, Based on the semantic asset candidates, dynamically generate controlled query plan instructions. The controlled query plan instructions are an intermediate representation that is completely decoupled from user input and maintained by the system itself. They are used to encapsulate the data source, indicator mapping, filtering conditions, business time range and return format of the query. S150: Parse the controlled query plan instruction and perform instruction-level validity status verification on the controlled query plan instruction based on the governed semantic assets; after the instruction-level validity status verification passes, translate the controlled query plan instruction into at least one parameterized SQL; perform dimension-level and indicator-level validity status verification on at least one parameterized SQL, and execute at least one parameterized SQL to obtain the data results after the verification passes. S160: Based on the data results, combined with the governed semantic assets and business rules, an encapsulated trusted data packet is generated, and an answer is generated based on the trusted data packet and returned to the user.

[0035] Specifically, the step of receiving natural language query requests in S110 is implemented by the input interaction module deployed in the query orchestration layer. The module provides a unified HTTP interface to the outside world, supporting request access from multiple channels such as BI workbench, enterprise portal, IM collaboration tools, open API and embedded entry. All requests must carry tenantId, userId and entry identifier parameters. The system first performs basic parameter verification on the request. After confirming that the tenant and user identities are legitimate, it generates a globally unique session identifier for new sessions that do not carry threadId. The threadId adopts UUID format and is generated by concatenating tenant ID, user ID, entry channel code and millisecond-level timestamp to ensure uniqueness throughout the system. For multi-round requests that carry a valid threadId, the context merging process is directly entered.

[0036] Simultaneously, the system will perform an initial judgment on the scope of managed questions. It employs a combined judgment logic of "rule vocabulary + topic domain configuration + lightweight classification model." First, the user's question is segmented and normalized. Then, it matches the configured topic keywords, indicator aliases, dimension aliases, and business action words to filter candidate topic domains. Next, it calls a lightweight text classification model to output the domain intent and confidence score. If the confidence score is greater than or equal to a set threshold (e.g., 0.75) and at least one enabled topic domain, indicator, or dimension alias is matched, the question is determined to be within the scope of managed questions, and the subsequent process continues. If the question matches non-manifest intents such as general chat, writing, code generation, translation, or marketing copywriting, or only an unenabled topic domain is matched, an unsupported status is directly returned, and the user is prompted to ask a manageable data query question instead, thus avoiding invalid requests consuming core layer resources.

[0037] The S120 multi-turn dialogue context merging and business term extraction are implemented in two sub-stages. First, context merging: the system uses a two-layer storage architecture of Redis memory caching and SQLite persistence to manage session context. Context data for active sessions is stored in Redis with a 30-minute expiration time. Session contexts that have not been interacted with after the expiration time are automatically transferred to the `conversation_context` table in SQLite for persistent storage. This table contains all context fields, including `threadId`, `tenantId`, `userId`, `turnId`, `lastSubject`, `lastMetricIds`, `lastDimensionIds`, `lastFilters`, `lastTimeRange`, `lastTimeGrain`, `lastPlanSummary`, `lastTraceId`, `createdAt`, and `updatedAt`. Upon receiving the current round request, the system... The `adId` is first read from Redis context; if the cache misses, it is retrieved from SQLite. The system then performs short follow-up question recognition on the user's natural language input. Using a combination of regular expression matching and a lightweight text classification model, it identifies typical follow-up question patterns such as "What about XX?", "Add XX", "View by month", "Change to last month", and "Only view the top 5". Following a coverage-first rule, field merging is performed: fields explicitly mentioned in the current request, such as city, time range, time granularity, and TopN ranking, directly override the corresponding values ​​from the previous round. Metrics, subject areas, and necessary dimensions not mentioned in the current round inherit the values ​​from the previous round. For example, if a user previously queried "national equipment rental volume" and now enters "What about Hangzhou?", the system will recognize this as a city dimension value replacement, replacing the city range in the filter conditions with Hangzhou, while keeping the metrics and subject areas unchanged. If the follow-up question is ambiguous and it's unclear whether it's a replacement or append operation, such as a user only entering "Add surrounding areas" without specifying a dimension, the corresponding field is marked as pending clarification to avoid semantic bias caused by guesswork.

[0038] After context merging is complete, the system enters the business primitive word extraction stage. It prioritizes calling the privately deployed semantic extraction large model service. The model can be from the Qwen series, GPT series, or a self-developed small model, deployed as an internal microservice interface. Request parameters include the merged user question text, the previous round's context summary, a list of candidate topic domains, a metric alias table, and a dimension alias table. The prompt word template strictly limits the model's role to "only extracting question semantic primitives, prohibiting the generation of any SQL statements, physical field names, or table names." The output is subject to mandatory constraints, including rawTerms, domainHint, metricWords, dimensionWords, and filt. The standard JSON structure of the erWords, timeRange, timeGrain, sortLimit, and confidence fields is used. If the model service is unavailable, the return format is abnormal, or the extraction confidence is lower than the threshold, the rule fallback logic is automatically triggered. Regular expressions are used to identify entities such as time expressions, TopN, region names, and device types. Then, combined with the alias mapping table, different expressions are unified into standard business primitives. For example, "rental volume", "number of rentals", and "number of rented devices" are unified into "number of devices rented". The entire extraction process only generates pure business semantic payloads and does not bind any final governance ID, reserving space for deterministic parsing in the subsequent core layer.

[0039] S130, the step of semantic parsing in the governed semantic asset knowledge base, specifically includes the following steps executed in parallel by the question number orchestration layer and the trusted core layer: The question number orchestration layer initiates a recall request to the governed semantic asset knowledge base based on the pure business semantic payload. The semantic asset knowledge base stores semantic slices obtained by slicing the de-identified business semantic content according to asset type, length or semantic field block. Each semantic slice contains a topic domain, indicator definition, dimension definition, time rules and query mode. The trusted core layer performs deterministic candidate parsing on pure business semantic payloads and returns structured parsing results that include indicator candidates, dimension candidates, rule hit status, and missing slots. Among them, deterministic candidate parsing includes alias exact matching, name inclusion matching, and semantic similarity matching based on a preset vector model. When the vectorization service or vector database is unavailable, the semantic asset knowledge base automatically degrades to a combined retrieval mode based on local inverted index or local exact match to ensure that the question-and-data link still provides basic query capabilities in the service degradation state. By aggregating the semantic slices returned by the semantic asset knowledge base and the structured parsing results returned by the trusted core layer, one or more semantic asset candidates pointing to the data query target are obtained.

[0040] Specifically, the S130 semantic asset knowledge base recall is supported by a robust knowledge governance system. Maintenance of all subject areas, metrics, dimensions, aliases, definition rules, and semantic assets is handled through a configuration management page. It supports batch import and incremental updates of files in CSV, JSON, and XLSX formats. After parsing the files, the system performs field validity checks to ensure each metric contains required fields such as a unique ID, name, definition, and applicable dimensions. Semantic slices are then generated according to a three-level slicing rule. First, slices are created by asset type, with structured semantic assets such as metrics, dimensions, entity values, and query templates forming independent blocks. Each metric corresponds to a main slice, containing complete information such as metric ID, name, definition, alias list, applicable dimensions, supported time granularity, and query mode. For long definition descriptions or business rule texts exceeding 800 characters, a second slicing is performed based on length, with each slice length controlled between 500-800 Chinese characters, and adjacent slices retaining 80-120 characters. To ensure semantic integrity, overlapping content is avoided. For assets imported in structured formats such as CSV and JSON, semantic field blocks are sliced, with "metric name + definition + alias + applicable dimension + example question" forming a complete semantic block for each slice. After slice generation, the slices are stored in the askbi_dw_knowledge table in SQLite and managed in batches. Each batch is assigned a unique batchId, and batch status, tenant isolation, and operator information are recorded. After review and confirmation, the slices are released and take effect. When the DashScope API key and pymilvus component are available, the system calls the qwen-embedding-v3 model to generate a vector representation for each slice, writes it to the Milvus vector library, and creates an IVF_FLAT index to improve retrieval efficiency. All semantic slices contain only anonymized business semantic content and do not store any physical table names, physical field names, table join conditions, or database connection information, thus avoiding the leakage of sensitive information from the storage level.

[0041] During the recall process, the system converts the user's original words and the concatenated text with context into vectors using an embedding model. Cosine similarity retrieval is then performed in Milvus to retrieve the Top 20 candidate slices. Simultaneously, keyword retrieval is performed in SQLite using the FTS5 full-text index, also retrieving the Top 20 results. The two sets of results are deduplicated and sorted by their combined score before being returned. When Milvus service is unavailable, embedding generation fails, or the vector index malfunctions, the system automatically degrades to a pure keyword retrieval mode, prioritizing FTS5 inverted index matching. If FTS5 is also unavailable, it degrades to a combination of "exact alias table matching + LIKE fuzzy matching." First, the exact aliases for the metrics and dimensions are matched using the alias table. Then, LIKE fuzzy matching is performed on the descriptive text to ensure that the query chain can still provide basic query capabilities even in service degradation scenarios, achieving high availability and fault tolerance.

[0042] Parallel to knowledge base retrieval is the deterministic semantic parsing of the trusted core layer, corresponding to the semantic / resolve interface of the trusted core layer. The interface input includes traceId, tenantId, userId, domainHint, rawTerms, subjectCandidates, contextTerms, and locale parameters. The core layer performs deterministic matching and parsing based on the semantic asset metadata maintained internally, rather than relying on the generative output of a large model.

[0043] The specific matching logic is as follows: first, the parsing scope is limited based on subjectCandidates, and then the indicator original terms, dimension original terms, and filter entities in rawTerms are matched and parsed deterministically with the indicator alias table, dimension alias table, and dimension entity value table, respectively.

[0044] Matching methods include exact alias matching, name inclusion matching, and semantic similarity matching based on a static vectorization library.

[0045] The specific implementation process of semantic similarity matching is as follows: In the knowledge governance stage, the pre-trained Embedding model is used to vectorize the governed semantic asset names, standard aliases, and definition texts to generate asset feature vectors and store them in the vector library; in the parsing stage, the same Embedding model is used to vectorize the user's business primitives to obtain query vectors; the cosine similarity between the query vector and the asset feature vectors within the specified range is calculated as the matching score.

[0046] To ensure the determinism of the parsing, the system sets strict validity rules: a valid match is only determined when the semantic similarity score is higher than a preset confidence threshold (e.g., 0.85) and the difference between this score and the comprehensive matching scores of other candidates is greater than a preset discrimination threshold (e.g., 0.1). Otherwise, it is considered an invalid match, and no candidate results are generated or the clarification process is triggered. This matching method based on a static feature library and rigid threshold rules eliminates random generation factors and ensures the unique reproducibility of the parsing results under the same input.

[0047] After parsing, a structured result is returned, including status, metricCandidates, dimensionCandidates, entityCandidates, timeRangeCandidates, ruleHits, missingSlots, clarificationHints, and traceId. For example, the original term "device rental volume" will match the "number of devices rented" metric with ID m_rented_device_cnt, with a score of 0.93, and the matching method is marked as alias. The original term "Hangzhou" will match the "Hangzhou" entity with ID 330100 under the d_city dimension, with a score of 0.95. The entire parsing process is based entirely on the managed semantic asset metadata and does not involve large model guessing, ensuring the determinism and reproducibility of semantic mapping.

[0048] After the parallel tasks of knowledge base retrieval and core layer semantic parsing return their results, the semantic candidate fusion module in the question number orchestration layer performs a unified summary and fusion process on the two outputs, outputting a standardized set of semantic asset candidates. This provides a consistent input basis for subsequent clarification judgments and the construction of controlled query plans. The entire fusion process strictly follows the credible principle of "core layer parsing results as the main factor and knowledge base retrieval results as the supplement." All candidates that ultimately take effect must be confirmed by deterministic parsing in the credible core layer. The semantic asset knowledge base results only serve as semantic supplements and information enhancements and do not have the qualification to take effect independently.

[0049] Before formal integration, the module first performs structured normalization processing on the two return results, mapping the original outputs of different formats to a unified SemanticAssetCandidate data structure. This structure uniformly includes fields such as asset type, subject domain ID, unique asset ID, asset standard name, matching source identifier, comprehensive matching score, list of original words of the matching user, alias set, business definition, list of applicable dimensions, and supported time granularity and analysis capabilities.

[0050] For the structured parsing results returned by the trusted core layer, each item in metricCandidates, dimensionCandidates, entityCandidates, and timeRangeCandidates is directly mapped to the corresponding candidate item by field. The initial score is the native matching score returned by the core layer, and the matching source is marked as Core deterministic parsing. The definition of scope and applicable dimensions are directly taken from the governance metadata maintained by the core layer. For the semantic slices returned by the knowledge base, they are first divided into indicator class, dimension class, entity value class, and query pattern class slices by the assetType field. Then, the fields such as assetId, assetName, aliases, metricDefinition, dimensionDefinition, and queryPatterns in the slice are mapped to a unified structure one by one. The initial score is the cosine similarity score of vector recall or the matching degree score of keyword retrieval. The matching source is marked as knowledge base recall. For query pattern and rule description class slices without a clear assetId, a slice ID is temporarily assigned as an identifier and classified into the supplementary semantic asset category.

[0051] After normalization, the module first performs precise primary key alignment based on the unique asset ID and subject domain. Under the constraint of the same subjectId, the core layer candidates with completely consistent assetId are merged with the knowledge base slices and merged into the same semantic asset candidate.

[0052] During the merging process, the standard name, unique ID, and effective status of assets are based on the governance metadata of the core layer. The business definition, alias list, applicable dimensions, and supported query modes are obtained by deduplicating the union of the two sets of content. If the core layer's definition is more concise, it is supplemented with detailed definitions from the knowledge base slices to ensure the completeness of candidate information. The matching score is calculated using a weighted fusion method, with the core layer parsing score accounting for 60%. This weighting is based on the core layer matching being based on the solidified governance asset metadata, which is a deterministic matching with the highest credibility. The knowledge base recall similarity score accounts for 25%, and the remaining 15% is allocated to the user's original word hit overlap. The user's original word hit overlap is calculated as follows: the number of matching characters between the business original words in the user's rawTerms and the candidate name and alias set is counted, and the total length of the matching characters is calculated as the proportion of the total length of the user's business original words. This proportion is directly used as the original word hit overlap score (the value ranges from 0 to 1). The final comprehensive matching score of the candidate is obtained by weighted summing of the three items.

[0053] Taking a user query for "monthly trend of equipment rental volume in Hangzhou" as an example, the original score of the candidate "equipment rental quantity" indicator returned by the core layer is 0.93, the similarity score of the same ID indicator slice vector recalled by the knowledge base is 0.91, the user's original word "equipment rental volume" completely matches the candidate alias, and the original word overlap score is 0.9. Therefore, the final comprehensive score of this candidate is 0.93×0.6+0.91×0.25+0.9×0.15, which is approximately 0.92 after calculation. At the same time, the detailed definition of the scope and the rules supporting monthly statistics in the knowledge base slice will be added to the candidate information to enrich the basis for subsequent plan construction.

[0054] For knowledge base slices without corresponding assetId, such as query pattern slices, business rule slices, and definition slices, the module performs semantic association matching within the topic domain. Using the same embedding model as the recall phase, the slice text is converted into a vector, and then cosine similarity is calculated between the vector and the name + definition vector of all core layer candidates. When the similarity is higher than the threshold of 0.8, the knowledge base slice is associated as a supplementary semantic asset with the extended information field of the corresponding candidate. For example, if the core layer returns a candidate for the number of rental devices, and the knowledge base recalls two query pattern slices, "summarize rental volume by region" and "get Top N ranking," and both have semantic similarity higher than the threshold, then these two analytical capabilities are added to the list of supporting analytical capabilities for that candidate indicator, providing a basis for constructing subsequent ranking and grouping query plans. If the similarity between the knowledge base slice and all core layer candidates is lower than the threshold, it is determined to be an irrelevant recall result and is directly filtered and discarded, not entering the final candidate set, to avoid irrelevant knowledge base content interfering with subsequent processes.

[0055] After alignment and association are completed, the module divides the candidates into four groups based on asset type: indicator candidate set, dimension candidate set, entity value candidate set, and analysis mode candidate set. Within each group, candidates are sorted in descending order of comprehensive matching score. Then, a deduplication operation is performed. The deduplication rule follows the principle of "unique with the same ID and distinguishable with the same name." For candidates with the same assetId, only the one with the highest comprehensive score is retained, and duplicate low-scoring entries are removed. For candidates with the same asset name but different assetIds and different business definitions, such as two different indicators with the same name "occupancy rate" but corresponding to "area occupancy rate" and "equipment quantity occupancy rate" respectively, all are retained, and the differences in definition and applicable scenarios are marked in the candidate information to provide a clear basis for subsequent ambiguity clarification. After sorting and deduplication, the module also performs semantic integrity verification on each indicator candidate. Based on the list of necessary dimensions for indicators defined in the core layer governance metadata, it checks whether the current set of dimension candidates and the set of entity candidates cover the necessary query conditions for the indicator. For example, the indicator "number of equipment rented" requires the inclusion of a time range dimension. If the current candidate set lacks time range-related candidates, it marks "missing time range" in the missingSlots field of the indicator candidate and passes the mark through to the subsequent clarification and interception stage. If all necessary dimensions of the indicator are covered, it is marked as having complete slots and has the basic conditions for generating a query plan.

[0056] For boundary scenarios where the two results do not overlap, the module also sets clear processing rules. If the core layer returns valid candidates but the knowledge base does not recall the corresponding slices, the core layer candidates are directly used as valid semantic assets, and the knowledge base is marked as missing. This does not affect the generation of subsequent query plans, only missing some detailed descriptions and extended analysis capabilities, which conforms to the core layer-based trust design. If the knowledge base recalls a large number of slices but the core layer does not parse out any valid candidates, it is determined that the query is outside the scope of governance. All knowledge base slices are not included in the valid candidate set, and the results are directly passed to subsequent stages to trigger unsupported prompts. This prevents assets that have not been confirmed by the core layer governance from entering the query plan construction stage, ensuring the credibility of semantic mapping from the source. After the above series of processing, the final output semantic asset candidate set has a unified data structure, clear score ranking, complete semantic information, and clear slot status. It can be directly input into the subsequent anti-illusion clarification and interception stage as the core basis for ambiguity judgment and conflict detection. It also provides standardized semantic input for subsequent restricted patch conversion and controlled query plan construction, ensuring semantic consistency throughout the entire chain from semantic parsing to plan generation.

[0057] Furthermore, after obtaining semantic asset candidates and before generating controlled query plan instructions, an anti-illusion forced clarification interception step is also included: Read the candidate comprehensive matching scores from the structured parsing results and determine ambiguity from two dimensions: absolute confidence and relative discriminability. When the highest comprehensive matching score of a candidate indicator is lower than the preset lower threshold (indicating insufficient overall matching confidence), it is determined to be semantic ambiguity. When the difference between the comprehensive matching scores of the highest candidate and the second highest candidate is less than the preset difference threshold (indicating the presence of confusing terms), it is also determined to be semantic ambiguity. When the same business term is mapped to multiple governance metrics with different calculation methods, or when the replacement and appending strategies for the same filtering dimension field cannot be determined when merging multiple rounds of dialogue context (i.e., fields marked as pending clarification during the context merging stage), it is identified as a slot conflict, and the corresponding field is marked as pending clarification. When semantic ambiguity or slot conflict occurs, the trusted core layer suspends the current query process, intercepts the generation of controlled query plan instructions, and returns a structured clarification question containing candidate options to the query orchestration layer, prohibiting the query orchestration layer from guessing metrics, dimensions, or entities to complete the semantics.

[0058] Specifically, after obtaining semantic asset candidates and before generating controlled query plan instructions, the anti-illusion forced clarification interception step is executed first. This is the core checkpoint to block guessing behavior. The interception logic is automatically determined based on the comprehensive matching score and slot status in the semantic asset candidates. The system presets two core thresholds: the lower limit of the highest confidence of the candidate indicator is set to 0.75, and the threshold for the difference between the highest and second-highest candidate is set to 0.10. The threshold settings are based on the accuracy statistics of a large amount of historical query data. When the comprehensive matching score of the candidate indicator is lower than 0.75, it indicates that the matching degree between the original word and the governance asset is insufficient, and forced mapping is prone to deviation. When the difference in the comprehensive matching score between the highest and second-highest candidate is less than 0.10, it indicates that there are two candidates with close similarity, and the system cannot uniquely determine the user's intent.

[0059] In addition to scoring, the system will also detect various slot conflict scenarios, including situations where the same business term can be mapped to multiple governance indicators with different calculation methods. For example, "occupancy rate" can correspond to two different indicators: "area occupancy rate" and "quantity occupancy rate," and the user's question is not clearly stated; user questions lack key slots such as subject domain, indicator, necessary time range, or necessary dimensions; filtered entities cannot fall within the range of governed dimension values; the operation type of the same filtering dimension cannot be determined when merging multiple rounds of context, for example, the user enters "add Jiangsu" but it is not clear whether it is to add to the existing city filter or replace it with the entire Jiangsu province; and scenarios where permission verification predicts that access is not possible.

[0060] When any ambiguous or conflicting scenario is triggered, the trusted core layer immediately suspends the current query process, sets the query status to pending clarification, intercepts all subsequent controlled query plan generation operations, and organizes candidate options to generate structured clarification results to return to the orchestration layer. For example, it may list the names and definitions of two candidate indicators for the user to choose from, or prompt the user to supplement the missing time range. The orchestration layer is only responsible for passing the clarification content to the front-end interactive interface and does not have the authority to select candidates, complete semantics, or skip clarification. This process eliminates the illusion problem caused by the orchestration layer guessing semantics.

[0061] Reference Figure 2 After the anti-illusion forced clarification interception step determines that the semantics are unique and no suspension is triggered, before generating the controlled query plan instruction, it further includes temporal version interleaving steps S210-S240: S210, Obtain the implied time range of facts in the natural language question count request; S220, for each semantic asset in the semantic asset candidate, read the registered temporal version information, wherein the temporal version information includes the effective start time, effective end time and version identifier; S230, the fact time range and the effective time range of multiple versions of each semantic asset are interleaved on the time axis to generate a versioned semantic asset list aligned by time segments, so that each entry in the versioned semantic asset list contains a non-overlapping time segment range and the version identifier corresponding to that time segment range. S240, the versioned semantic asset list is recorded in the controlled query plan instruction as a segmented query plan data structure. The segmented query plan contains at least two time segments and version identifiers and definition texts corresponding to each time segment. Finally, when translating to generate parameterized SQL, each time segment is independently translated into a subquery with a version identifier, and a version definition field is attached to the returned result data set.

[0062] Specifically, after completing the clarification and interception and determining semantic uniqueness, the system executes a temporal version interleaving segmentation step to resolve the inconsistency in query definitions caused by changes in indicator definitions over time. This implementation relies on the temporal version metadata of semantic assets and a timeline interleaving segmentation algorithm. First, the system parses the factual time range queried by the user from the `timeRange` field of the original business term. If it is a relative time expression such as "last month" or "last six months," it is first converted to an absolute date range based on the current date. Then, for each candidate semantic asset, all historical version information of that asset is read from the semantic asset temporal version table. The temporal version table is... Each metric and dimension maintains an independent version record. Each record contains a version identifier, effective start date, effective end date, definition text, and corresponding physical mapping rules. Versions that are currently in effect are marked as permanently valid upon their end date. Next, a timeline staggered segmentation algorithm is executed. This algorithm is mainly for semantic assets of metric type with independent temporal version changes. For multiple metric or dimension assets involved in the same query, the system uses the version change time points of each asset as the common segmentation node, and takes the union of the version time points of all assets for unified segmentation to ensure that the version of all referenced assets within the same sub-time segment is uniquely determined. The specific steps are as follows: First, merge and deduplicate the starting point of the factual time interval with the effective start time of all relevant asset versions, and sort them chronologically to form a set of time node sequences; then, traverse each adjacent time node as a candidate sub-interval, and determine whether the candidate sub-interval falls within both the factual time interval and the effective time interval of a certain version; if it falls within both, retain the candidate sub-interval as a sub-time segment and record the corresponding version identifier; if it does not fall within any intersection, skip it; finally, split the original factual time interval into several non-overlapping continuous sub-time segments, each sub-time segment uniquely corresponding to an effective version. For example, if a user queries the number of devices rented from June 2025 to June 2026, and this indicator uses the "number of devices rented at the end of the period" metric before December 31, 2025, and the "average number of devices rented per day" metric from January 1, 2026 onwards, then the algorithm will divide the query period into two segments: June 1, 2025 to December 31, 2025, and January 1, 2026 to June 30, 2026, corresponding to versions v1 and v2 respectively.

[0063] After segmentation, the system writes the list of versioned semantic assets into the segmented query plan structure of the controlled query plan. Each segment contains the corresponding time segment range, version identifier, and definition text. In the subsequent SQL translation stage, the trusted core layer will independently generate parameterized subqueries for each time segment. Finally, the results of multiple subqueries will be concatenated into a complete result set through UNION ALL. The returned trusted data package will have an additional version_caliber field to mark the version and definition of the indicator for different time periods, ensuring that users can clearly understand the differences in the definitions for different time periods and avoid data misunderstandings caused by changes in definitions.

[0064] Reference Figure 3 S140, the step of dynamically generating controlled query plan instructions based on semantic asset candidates, specifically includes controlled construction steps S310-S330 based on the whitelist patch merging mechanism: S310 converts the semantic asset candidates and the assets recalled by the semantic asset knowledge base into restricted patches. S320 performs field scanning on restricted patches, allowing only whitelisted fields containing subject domain scope, business node, edge, output format, guardrail, and business query semantic fields to be written into the controlled query plan instruction; it explicitly rejects physical execution fields containing structured query language text, data source identifier, physical table name, physical column name, physical join condition, or permission filtering condition. S330: When merging multiple restricted patches, if the same field path is written with different values ​​by different restricted patches and is not declared as append mode, it is determined that the same path is mutually exclusive, the merge is rejected and a clarification request is returned.

[0065] Specifically, in step S140, the system constructs the controlled query plan instruction. Based on the query patterns and dependencies in the semantic asset candidates, the system identifies the plan type for this query and writes this plan type into the controlled query plan instruction. Subsequently, the system converts the candidate results of Core semantic parsing, the semantic assets recalled from the knowledge base, and the query parameters inherited from the context into standard-format restricted patches. Each restricted patch contains only its corresponding semantic fields. Before merging the restricted patches, the system performs a full field scan, validating the field validity of each patch based on a pre-defined whitelist JSON Schema. The whitelist only allows `planType`, `subjectScope`, `metrics` under `query`, and `dimensions`. Business semantic fields such as ons, filters, timeRange, timeGrain, having, and analysis, as well as plan structure fields such as nodes, edges, output, and guardrails (guardrails used to define execution boundary limits such as maximum number of returned rows, query timeout, and data anonymization level), will be directly rejected. Any patch containing physical execution class and sensitive class fields such as sql, compiledSql, datasource, physicalTable, physicalColumn, join, and permissionFilter will be directly rejected to ensure that no underlying physical information appears in the plan constructed by the orchestration layer.

[0066] When merging patches, a mutual exclusion rule for the same path is followed. The system traverses the field paths of all patches through JSONPath. If two different patches write different values ​​to the same field path, and the patches are not declared as append mode, it is determined to be a field conflict. For example, if one patch sets the time range to "this month" and another patch sets it to "last month", the merge will be rejected and a clarification request will be generated to inform the user that there is a time range conflict and to choose one. If the patch is declared as append mode and the corresponding field supports multiple values, such as the IN operator for city filtering, the values ​​of multiple patches will be merged into a list. For example, the city filter will be merged into **city IN ['Hangzhou', 'Ningbo']**. Patch priority follows the rule that "Core parsing results take precedence over knowledge base retrieval results, and user explicit expressions in this round take precedence over historical context inheritance". When patches from different sources have non-mutually exclusive hierarchical differences, the final value is determined by the priority.

[0067] After the merge is complete, the system will perform a full verification of the whitelist schema again to ensure that the final generated controlled query plan instructions fully comply with the field constraints and do not contain any prohibited fields. For example, the final plan corresponding to "query the number of equipment rentals in Hangzhou" is a standard PlanDSL structure that includes the SIMPLE_SQL type, asset operation subject domain, equipment rental quantity index, city dimension and Hangzhou filtering conditions, without involving any physical layer information.

[0068] The controlled query plan instruction contains a topology structure consisting of nodes and edges. After generating the controlled query plan instruction, it further includes a node topology dependency verification step. Read the plan type from the controlled query plan instruction, and perform corresponding topology validity checks for different plan types, including: when the plan type is parallel, verify that there are no data dependencies between nodes; when the plan type is sequential or directed acyclic graph, verify the validity of field references in nodes; when the plan type is branching, verify whether the condition reference fields of branch nodes are bound in the declaration fields of upstream nodes; when the plan type is iterative, verify whether the drill-down path, selection rules, and stopping conditions of iterative nodes come from the enabled semantic asset configuration. If the verification fails, the query number arrangement layer will refuse to allow itself to perform a loop query or jump query, and will block the subsequent translation process.

[0069] Specifically, for controlled query plans containing complex topologies such as branches and iterations, the system performs topology validity checks after plan generation and before submission to Core for verification, preventing the orchestration layer from constructing illegal execution logic. The verification logic is executed according to planType. For PARALLEL_SQL type, it checks that there are no edge connections between all semantic_query nodes, ensuring that each subquery is completely independent and can be executed in parallel, prohibiting data dependencies between nodes. For example, querying the rental volume of Hangzhou and Ningbo simultaneously as two independent sub-nodes meets the parallel execution requirement. For SEQUENCE_SQL and DAG_SQL types, it checks the output fields referenced by the valueFrom field of each node, ensuring they come from the output declared field set of its upstream node. For example, if the second query needs to use the Top 5 city list obtained from the first query as a filter condition, the output of the first step must explicitly declare the city field, and the valueFrom of the second step must accurately reference this field. If a non-existent field is referenced, the verification fails. For BRANCH... For the _SQL type, the fields referenced in the branch judgment conditions must come from the output results of the upstream nodes, and the node IDs pointed to by trueNode and falseNode must exist in the node list of the current plan. Jumping to execution logic outside the plan is prohibited. For example, in the branch query "If the inventory is insufficient, check the procurement suggestion; otherwise, check the allocation suggestion", the inventory gap field must come from the upstream query result, and the two branch nodes must be semantic query nodes defined in the plan. For the ITERATIVE_SQL type, the drill-down path, node selection rule, and stop condition are strictly validated. All three must come from the semantic asset configuration enabled under the current subject domain, that is, the drill-down path rules predefined in the configuration management page, such as the standard drill-down link from region to city to store. The orchestration layer does not have the permission to customize the drill-down path, the number of loops, or the stop condition. If the validation finds that any parameter comes from a non-configuration source, the plan will be rejected directly and the subsequent translation process will be blocked to prevent the orchestration layer from accessing the unmanaged data range through loop queries.

[0070] S150 specifically includes a two-stage trusted execution step: In the first phase, the trusted core layer parses the controlled query plan instructions and performs execution mode verification, subject domain verification, dimension compatibility verification, time range verification, row and column level permission verification, and instruction level compliance verification on the controlled query plan instructions and the effective status of the semantic assets contained therein, based on the governed semantic assets. At the same time, it injects controlled permission filtering conditions into the controlled query plan instructions according to the current user's permissions. In the second phase, the trusted core layer translates and compiles the controlled query plan instruction after injecting controlled permission filtering conditions into at least one parameterized SQL using placeholders and parameter binding; then, it performs dimensional and metric-level validity status verification on the generated parameterized SQL; it rejects SQL fragments concatenated by the application layer and pushes the parameterized SQL that passes the verification into the execution queue for execution to obtain data results; The trusted core layer encapsulates metadata, including data rows, metric definitions, time ranges, data source versions, permission ranges, quality tips, and cross-version segmentation marker fields, into a trusted data package and returns it to the query orchestration layer.

[0071] Specifically, after the controlled query plan that passes S150 verification is submitted to the trusted core layer, the core layer adopts a two-stage execution mechanism that separates verification and execution. The entire process is completed in a closed loop within the core layer, and all physical information and execution logic are not transmitted to the orchestration layer. The first stage is the plan verification stage, corresponding to the plan / validate interface of the trusted core layer. After receiving the controlled query plan, the core layer performs multi-dimensional verification in sequence: Schema verification verifies the legality of the field structure, data type, and node dependency relationship of the plan based on the standard JSON Schema, preventing plans with abnormal structures from entering the subsequent process; Subject domain verification queries the tenant's subject domain configuration table to confirm the su in the plan. bjectId belongs to the current tenant and is in an enabled state to prevent unauthorized access from cross-tenant or offline topics; metric caliber verification checks the metadata corresponding to each metricId to confirm that the metric has a unique and valid caliber and standard aggregation method to avoid confusion between multiple calibers; instruction-level compliance verification is used to confirm that the subject domain and plan template corresponding to the entire controlled query plan instruction are currently in a macro-effective state of being published and not disabled, and comply with the preset structural specifications and business rules; the subsequent second phase of dimension-level and metric-level effectiveness status verification is for each individual dimension and metric asset specifically referenced in the plan to verify whether it is in an independent effective time window or is disabled individually.

[0072] Dimension compatibility verification checks the relationship table between query metrics and dimensions, confirming that all dimensions in the plan can be queried with their corresponding metrics, and excluding dimension-metric combinations that cannot be combined. Time range verification converts relative time expressions in the plan into precise start and end dates, and also checks whether the time span exceeds the maximum query range configured for the subject domain; for example, the maximum span for a single query on a single subject is 3 years. Permission verification connects to the enterprise's unified permission center, querying the corresponding row and column-level access permissions based on the current user's tenantId, userId, and role information. Row-level permissions are then converted into corresponding dimension filter conditions and injected into the plan's filter. In the `rs` (Remote Sensing) layer, for example, if a user can only view data from the East China region, an East China region filter is automatically added at the city level. Column-level permissions are marked with desensitization rules for sensitive indicators; for example, salary-related indicators are blurred when returned. Rate limiting checks use Redis counters to count the daily and minute-level call frequency for tenants, users, and subject domains. Requests exceeding the rate limiting threshold are directly rejected. Execution feasibility checks estimate the amount of data to be scanned and the number of rows to be returned for the current query based on the time range, dimension cardinality, and historical data volume statistics. If the estimated number of rows to be returned exceeds the `maxRows` setting in `guardrails`, the user is prompted to narrow down the query scope. After all checks pass, the core layer sends the permission-filtered plan to the second stage, corresponding to the `plan / run` interface.

[0073] The second stage is the SQL translation and execution stage. Based on the semantic-physical mapping metadata maintained internally, the core layer maps the semantic metrics and semantic dimensions in the plan to the corresponding physical table names, physical field names, and aggregation logic. Combining filtering conditions, time ranges, and sorting constraints, parameterized SQL is generated using placeholders and parameter binding. All user input values ​​are passed as bound parameters and are not directly concatenated into the SQL statement. For example, an SQL template of "where city = ? andbiz_date between ? and ?" is generated. The actual parameters are uniformly bound by the core layer according to the DSL and permission filtering, thus avoiding the risk of SQL injection at the source. For segmented plans with temporal versioning, a subquery corresponding to each time segment is generated independently, and then concatenated into a complete SQL using UNION ALL.

[0074] After the SQL is generated, the system will perform a second validity check to confirm that the semantic assets and physical mappings used in the translation are the current effective versions, and avoid using mapping rules that have been taken offline. After the check passes, the parameterized SQL is pushed into the execution queue and the query is executed through JDBC connection to the corresponding data warehouse or BI indicator platform to obtain the data result set. The entire translation and execution process is completed inside the core layer, and the orchestration layer cannot obtain any SQL fragments, physical table information or database connection parameters.

[0075] After the query is executed, the trusted core layer encapsulates the data results and accompanying metadata into a standard trusted data packet and returns it to the query orchestration layer. The data packet contains traceId, planType, rows result set, columns semantic column mapping, metricDefinitions metric definition, filters business filtering conditions, timeRange precise time range, dataSources data source, permissionScope permission scope description, qualityHints data quality hints, warnings alarm information, and crossVersionFlag cross-version segmentation flag field (used to indicate whether this query triggered temporal version interleaving). All fields are readable information at the business semantic level and do not contain any underlying technical details. For example, in the query results for Hangzhou equipment rental volume, it will clearly indicate that the metric definition is "the number of devices in the rental state at the end of the statistical period", the data source is the BI metric platform v202605 version, the permission scope is East China region, and the data is updated on T+1, ensuring that the results are transparent and interpretable.

[0076] Reference Figure 4 Before generating a response based on trusted data packets, the process further includes confidence assessment and anomaly interception steps S410-S440 based on multi-dimensional state linkage: S410 pre-builds a lightweight statistical distribution model for each commonly used query pattern or semantic asset combination. The statistical distribution model includes expected value range, standard deviation and typical order of magnitude information, and is dynamically updated by historical valid query results. S420 matches the data characteristics in the trusted data packet with the corresponding statistical distribution model and calculates the anomaly degree of the result; S430, when the abnormality of the result is greater than the preset threshold, it is determined to be a low confidence result, enters the active avoidance state, intercepts the direct output of the trusted data packet, triggers the intent drift state assessment, and reads the cross-version segmentation marker field in the trusted data packet to determine whether there is a cross-version segmentation record in this query. S440 If the query finds that the intent drift status is severely drifted or that there are cross-version segmentation records, the identifier corresponding to the change in the caliber version or the switch of the analysis topic will be written first in the speculative reason field of the generated structured confidence feed message. The structured confidence feed message will be returned to the user for confirmation, and the statistical distribution model will be updated according to the user's feedback data.

[0077] Specifically, after receiving a trusted data packet, the query orchestration layer does not return it directly to the user. Instead, it first performs confidence verification through the result anomaly detection module. The system pre-builds a lightweight statistical distribution model for each commonly used indicator + dimension combination. The model is trained based on the legitimate query results of the past 90 days and includes the expected value range, standard deviation, typical order of magnitude, and quantile information of the indicator value. This model is stored in the statistical model library and updated daily. When calculating anomalies, the system extracts the numerical features of the indicator in the current query and matches them with the corresponding statistical distribution model. It calculates the standard deviation multiple of the result from the mean. If the deviation exceeds 3 times the standard deviation, it is determined that the result anomaly exceeds the standard, and the system enters an active avoidance state, intercepting the direct output of the result. If the anomaly does not exceed the preset threshold, it is determined to be a normal confidence result. The system does not perform additional interception and directly sends the trusted data packet to the subsequent result expression stage. At the same time, it asynchronously updates the indicator value, dimension combination, and time range information of the current query to the corresponding statistical distribution model incrementally. Through continuous iteration of normal samples, the expected value and standard deviation parameters of the model are optimized to ensure that the statistical distribution always fits the actual fluctuation of the current business data. In addition, for cold-start query combinations that have not established a statistical distribution model or low-frequency combinations with a historical sample count lower than a preset threshold, the system directly determines them as normal confidence results and allows them to pass. The query result is then used as an initial sample to be included in the model's cold-start accumulation. The anomaly calculation and interception mechanism will be officially activated once the sample size reaches the threshold.

[0078] After entering active avoidance mode, the system will backtrack the query context, calculate the cosine similarity based on the core semantic vectors of the current and previous queries to determine the intent drift level of the current query, and check for any temporal version interleaving records. Intent drift here measures the continuity of the user's query intent across multiple rounds of dialogue. For the first query or scenarios where the context has been reset, the system directly determines there is no drift and skips the similarity calculation. For multi-round dialogues, the system calculates the cosine similarity based on the core semantic vectors of the current and previous queries, and makes a comprehensive judgment based on topic domain affiliation and indicator category overlap. Severe drift refers to the current query belonging to a completely different topic from the previous query. In scenarios where the core indicator systems have no business overlap and the semantic similarity is below 0.3, such as when the previous query was for the number of devices rented under the asset operation theme, and the current query jumps directly to the total employee salary under the human resources theme without transition, the data volume and statistical caliber are fundamentally different, and it is normal for the results to deviate from the historical distribution. In contrast, slight drift refers to the reasonable expansion of indicators or dimensions within the same topic domain, with semantic similarity in the range of 0.3 to 0.6. For example, switching from a rental volume query to an idle rate query still belongs to the relevant analysis within the same business domain. No drift refers to semantic similarity above 0.6, which is a routine follow-up question such as dimension filtering and time range adjustment.

[0079] If a query reveals severe intent drift or cross-version segmentation records, the generated structured confidence feed message's reason field will prioritize writing an identifier corresponding to the version change or analysis topic switch. For example, "The query result deviates significantly from the historical range because the equipment rental quantity indicator was adjusted in January 2026. Please confirm whether you wish to continue viewing." The structured confidence feed message will be returned to the user for confirmation, and the statistical distribution model will be updated based on the user's feedback. If the user confirms that the result matches business expectations, the data will be included in the statistical sample of the corresponding topic. If the user denies it, it will be marked as an abnormal sample and will not participate in the model update.

[0080] If the query finds only slight drift or no drift (i.e., no drastic jump across subject domains), the system determines that the anomaly is not caused by a macro-level scenario switch and instead investigates micro-level causes, such as extreme filtering conditions, sparse dimension combinations, or special time windows. For example, if only daily data from a single, less popular store is filtered, or business metrics during the Spring Festival holiday are statistically analyzed, the system will generate corresponding business-specific prompts, such as "This query has a very fine filtering dimension and a limited data sample size, so the numerical fluctuations may be large. It is recommended to combine it with a wider range of data for comprehensive reference." The system will also mark the result with a low-confidence warning and return it to the user. At the same time, the result will be marked as a sample to be reviewed and will not be included in the statistical distribution model for the time being. The model parameters will be updated after subsequent similar queries are accumulated or after manual review and confirmation. This avoids normal special business scenarios being erroneously blocked and also prevents abnormal data from polluting the baseline distribution of the statistical model. If the user reports that the result is incorrect, a manual review process will be triggered to simultaneously check the semantic asset mapping and the quality of the underlying data. Based on the review results, the semantic asset configuration will be updated or the statistical model parameters will be corrected.

[0081] In S160, the results presentation module generates visual metadata and response text based on trusted data packets, without modifying the original data in the data packets. The generation of visual metadata follows fixed rules: if the result set contains a continuous time field and at least three data points at the time granularity, a line chart candidate configuration is automatically generated, with time as the X-axis and the indicator value as the Y-axis; if it contains a time field but only compares a small number of discrete time periods, a bar chart candidate is generated; if it contains one category dimension and one numerical indicator, a grouped bar chart candidate is generated; if the number of values ​​for the category dimension does not exceed eight and the indicator is a percentage indicator, a pie chart candidate is generated; if it contains two or more dimensions or detailed fields, it is displayed in a table format by default; the front end prioritizes displaying tables by default, and users can manually switch the chart type in the results area.

[0082] The response text will fully display the traceId, indicator definition, query time range, effective filtering conditions, data source, permission scope, and data quality prompts to ensure that all query results are traceable and interpretable. Recommended follow-up questions employ a dual verification mechanism of template generation and semantic mapping. First, based on the current query's topic domain, indicators, and supported analytical capabilities, candidate follow-up questions are generated from preset templates, such as "expand by city," "view trends by month," and "view Top 5 device types." Then, each candidate follow-up question is mapped back to its corresponding semantic ID and analytical capability to confirm that it falls within the scope of governance and can be correctly parsed by the core layer. Follow-up questions that cannot be mapped are filtered out, ensuring that users can execute queries normally after clicking on recommended follow-up questions and avoiding unrecognized situations.

[0083] Finally, the system performs differentiated context saving based on the query execution status: If the query completes normally, the system updates the context storage with information such as the topic domain, metrics, dimensions, filtering conditions, time range, plan summary, and traceId of this round of query, overwriting the old context data; if the query is suspended due to triggering anti-illusion forced clarification interception, the system only updates the candidate options to be clarified and the current suspension status identifier to the context storage, retaining the valid query context data from the previous round, and merging and updating it after the user replies with clarification questions. Simultaneously, the entire chain log is written to the audit system, recording the requesting user, request time, semantic parsing results, execution plan, result summary, and exception information, meeting the enterprise's audit and traceability requirements.

[0084] Based on the above method embodiments, the second embodiment of this application discloses a natural language intelligent question-and-answer system based on a trusted semantic core. The natural language intelligent question-and-answer system based on a trusted semantic core in this embodiment can implement any of the above-described natural language intelligent question-and-answer methods based on a trusted semantic core, and the specific working process of each module in the natural language intelligent question-and-answer system based on a trusted semantic core can be referred to the corresponding process in the above method embodiments.

[0085] For ease of understanding, an example is given below: A natural language intelligent question counting system based on a trusted semantic core is physically and logically separated into a question counting arrangement layer and a trusted core layer, including: The input interaction module, deployed in the question orchestration layer, is used to receive natural language question requests from users. The intelligent agent orchestration module deployed in the question orchestration layer is used to query the saved historical context and merge the natural language question request with the historical context through multi-turn dialogue context. The semantic processing module deployed in the question number orchestration layer is used to perform word segmentation and normalization on the merged requests, extract business original words, and generate pure business semantic payloads. The knowledge governance module, deployed in the question data orchestration layer, contains a governed semantic asset knowledge base. It is used to initiate recall requests to the semantic asset knowledge base based on pure business semantic payloads to obtain semantic slices. The semantic parsing module, deployed in the trusted core layer, is used to perform deterministic candidate parsing on pure business semantic payloads, return structured parsing results, and converge with semantic slices to obtain semantic asset candidates. The domain-specific language construction module deployed in the query orchestration layer is used to dynamically generate controlled query plan instructions based on semantic asset candidates. The controlled query plan instructions are an intermediate representation that is completely decoupled from user input and maintained by the system itself. They are used to encapsulate the query data source, indicator mapping, filtering conditions, business time range and return format. The trusted execution module, deployed in the trusted core layer, is used to parse controlled query plan instructions, translate them into at least one parameterized SQL statement based on the governed semantic assets and the verification of the semantic assets' effectiveness status, and perform dimensional and metric-level effectiveness status verification on at least one parameterized SQL statement. After the verification passes, at least one parameterized SQL statement is executed to obtain data results; and based on the data results, combined with the governed semantic assets and business rules, a packaged trusted data package is generated. The result presentation module, deployed in the question orchestration layer, is used to generate answers based on trusted data packets and return them to the user.

[0086] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0087] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A natural language intelligent question-answering method based on a trustworthy semantic core, characterized in that, include: Receive natural language question requests from users; The saved historical context is queried, and the natural language question number request is merged with the historical context through multi-turn dialogue context. The merged request is then segmented and normalized, and business original words are extracted to generate pure business semantic payload. Based on the pure business semantic payload, semantic parsing is performed in the governed semantic asset knowledge base to obtain one or more semantic asset candidates pointing to the data query target; Based on the semantic asset candidates, a controlled query plan instruction is dynamically generated. The controlled query plan instruction is an intermediate representation that is completely decoupled from user input and maintained by the system itself. It is used to encapsulate the data source, indicator mapping, filtering conditions, business time range and return format of the query. The controlled query plan instruction is parsed, and its effective status is verified at the instruction level based on the governed semantic assets. After the instruction-level effective status verification passes, the controlled query plan instruction is translated into at least one parameterized SQL statement; Perform dimension-level and metric-level validity status verification on the at least one parameterized SQL statement. After the verification passes, execute the at least one parameterized SQL statement to obtain the data results. Based on the data results, combined with the governed semantic assets and business rules, an encapsulated trusted data packet is generated, and an answer is generated based on the trusted data packet and returned to the user.

2. The natural language intelligent question-answering method based on a trustworthy semantic core according to claim 1, characterized in that, The natural language intelligent question counting method is executed collaboratively and interactively between the mutually isolated question counting orchestration layer and the trusted core layer; In a specific stage of semantic parsing, the two layers support parallel processing and result aggregation; The question number orchestration layer performs the steps of receiving the natural language question number request, merging the multi-turn dialogue context, and extracting business primitives, and transmits the generated pure business semantic payload to the trusted core layer. The trusted core layer performs the steps of semantic parsing, generating the controlled query plan instruction, parsing and verifying the controlled query plan instruction, translating and verifying the parameterized SQL, and executing the parameterized SQL to obtain data results; wherein, the physical table name, physical field name, physical table join conditions, and database connection information are encapsulated within the trusted core layer, and the parameterized SQL is independently compiled and generated by the trusted core layer and is not passed through to the query orchestration layer. The question number orchestration layer receives the trusted data packets returned by the trusted core layer and interprets and visualizes the trusted data packets.

3. The natural language intelligent question-answering method based on a trustworthy semantic core according to claim 2, characterized in that, The steps involved in semantic parsing within the governed semantic asset knowledge base specifically include the following steps, executed in parallel by the question number orchestration layer and the trusted core layer: The question number orchestration layer initiates a recall request to the managed semantic asset knowledge base based on the pure business semantic payload. The semantic asset knowledge base stores semantic slices obtained by slicing the de-identified business semantic content according to asset type, length or semantic field block. Each semantic slice includes a topic domain, indicator definition, dimension definition, time rule and query mode. The trusted core layer performs deterministic candidate parsing on the pure business semantic payload, and returns a structured parsing result that includes indicator candidates, dimension candidates, rule hit status, and missing slots; wherein, the deterministic candidate parsing includes alias exact matching, name inclusion matching, and semantic similarity matching based on a preset vector model; When the vectorization service or vector database is unavailable, the semantic asset knowledge base automatically degrades to a combined retrieval mode based on local inverted index or local exact match to ensure that the question-and-data link still provides basic query capabilities in the service degradation state. By summing the semantic slices returned by the semantic asset knowledge base and the structured parsing results returned by the trusted core layer, one or more semantic asset candidates pointing to the data query target are obtained.

4. The natural language intelligent question-answering method based on a trustworthy semantic core according to claim 3, characterized in that, After obtaining semantic asset candidates and before generating the controlled query plan instruction, the process also includes an anti-illusion forced clarification interception step: Read the candidate comprehensive matching scores in the structured parsing results. When the highest comprehensive matching score of the candidate index is lower than the preset lower threshold, it is determined to be semantic ambiguity; when the difference between the comprehensive matching scores of the highest candidate and the second highest candidate is less than the preset difference threshold, it is also determined to be semantic ambiguity. When the same business term is mapped to multiple governance metrics with different calculation methods, or when the replacement and appending strategies for the same filtering dimension field cannot be determined when multiple rounds of dialogue context are merged, it is identified as a slot conflict, and the corresponding field is marked as pending clarification. When the semantic ambiguity or slot conflict occurs, the trusted core layer suspends the current query process, intercepts the generation of the controlled query plan instruction, and returns a structured clarification question containing candidate options to the question number orchestration layer, prohibiting the question number orchestration layer from guessing metrics, dimensions, or entities to complete the semantics.

5. A natural language intelligent question-answering method based on a trustworthy semantic core as described in claim 1 or 4, characterized in that, The steps for dynamically generating controlled query plan instructions based on semantic asset candidates specifically include controlled construction steps based on a whitelist patch merging mechanism: Convert the semantic asset candidates and the assets recalled by the semantic asset knowledge base into restricted patches; The restricted patch is scanned for fields, and only whitelisted fields containing subject domain scope, business node, edge, output format, guardrail and business query semantic fields are allowed to be written into the controlled query plan instruction; physical execution fields containing structured query language text, data source identifier, physical table name, physical column name, physical join condition or permission filtering condition are explicitly rejected. When merging multiple restricted patches, if the same field path is written with different values ​​by different restricted patches and is not declared as append mode, it is determined that the same path is mutually exclusive, the merge is rejected and a clarification request is returned.

6. The natural language intelligent question-answering method based on a trustworthy semantic core according to claim 5, characterized in that, The controlled query plan instruction includes a topology structure composed of nodes and edges. After generating the controlled query plan instruction, a node topology dependency verification step is further included. The plan type in the controlled query plan instruction is read, and corresponding topology validity checks are performed for different plan types, including: when the plan type is parallel, checking that there is no data dependency between nodes; when the plan type is sequential or directed acyclic graph, checking the validity of field references of nodes; when the plan type is branching, checking whether the condition reference fields of branch nodes are bound in the declaration fields of upstream nodes; when the plan type is iterative, checking whether the drill-down path, selection rules, and stopping conditions of iterative nodes come from enabled semantic asset configurations. If the verification fails, the query number arrangement layer will refuse to allow itself to perform a loop query or jump query, and will block the subsequent translation process.

7. The natural language intelligent question-answering method based on a trustworthy semantic core according to claim 2, characterized in that, The process involves parsing the controlled query plan instruction, translating it into at least one parameterized SQL statement based on the governed semantic assets and the verification of the semantic assets' effectiveness status, and then performing dimensional and metric-level effectiveness status verifications on the at least one parameterized SQL statement. After successful verification, the at least one parameterized SQL statement is executed to obtain the data result. This process specifically includes a two-stage trusted execution step. In the first phase, the trusted core layer parses the controlled query plan instruction and performs mode verification, topic domain verification, dimension compatibility verification, time range verification, row and column level permission verification, and instruction level compliance verification on the controlled query plan instruction and the effective status of the semantic assets contained therein, based on the governed semantic assets. At the same time, it injects controlled permission filtering conditions into the controlled query plan instruction according to the current user's permissions. In the second stage, the trusted core layer translates and compiles the controlled query plan instruction after injecting controlled permission filtering conditions into at least one parameterized SQL using placeholders and parameter binding; then, the generated parameterized SQL is validated at the dimension and indicator levels to verify its effectiveness. Reject application-layer SQL fragments and push the validated parameterized SQL into the execution queue to obtain the data results; The trusted core layer encapsulates metadata, including data rows, indicator definitions, time ranges, data source versions, permission ranges, quality prompts, and cross-version segmentation marker fields, into a trusted data packet and returns it to the question data orchestration layer.

8. The natural language intelligent question-answering method based on a trustworthy semantic core according to claim 4, characterized in that, Before generating the controlled query plan instruction after the anti-hallucination forced clarification interception step determines that the semantics are unique and no suspension is triggered, a temporal version interleaving segmentation step is further included: Obtain the implicit time range of facts in the natural language question count request; For each semantic asset in the semantic asset candidate, the registered temporal version information is read, wherein the temporal version information includes the effective start time, the effective end time, and the version identifier; The factual time range and the effective time range of multiple versions of each semantic asset are interleaved on the time axis to generate a versioned semantic asset list aligned by time segments, such that each entry in the versioned semantic asset list contains a non-overlapping time segment range and a version identifier corresponding to the time segment range. The versioned semantic asset list is recorded in the controlled query plan instruction as a segmented query plan data structure. The segmented query plan contains at least two time segments and version identifiers and definition texts corresponding to each time segment. Finally, when the parameterized SQL is generated, each time segment is independently translated into a subquery with a version identifier, and a version definition field is attached to the returned result data set.

9. A natural language intelligent question-answering method based on a trustworthy semantic core as described in claim 7 or 8, characterized in that, Before generating a response based on the trusted data packet, the process further includes confidence assessment and anomaly interception steps based on multi-dimensional state linkage: A lightweight statistical distribution model is pre-built for each commonly used query pattern or semantic asset combination. The statistical distribution model includes expected value range, standard deviation and typical order of magnitude information, and is dynamically updated by historical valid query results. The data features in the trusted data packet are matched with the corresponding statistical distribution model, and the anomaly degree of the result is calculated; When the abnormality of the result exceeds a preset threshold, it is determined to be a low-confidence result, enters an active avoidance state, intercepts the direct output of the trusted data packet, triggers intent drift state assessment, and reads the cross-version segmentation marker field in the trusted data packet to determine whether there is a cross-version segmentation record in this query; intent drift is used to measure the continuity of the user's query intent in multi-turn dialogue; If the query finds that the intent drift status is severely drifted or that there are cross-version segmentation records, then the identifier corresponding to the change in the caliber version or the switch of the analysis topic will be written first in the speculative reason field of the generated structured confidence feed message. The structured confidence feed message will be returned to the user for confirmation, and the statistical distribution model will be updated according to the user's feedback data.

10. A natural language intelligent question-and-answer system based on a trusted semantic core, characterized in that, The natural language intelligent question counting method based on a trusted semantic core, as described in any one of claims 1 to 9, is physically and logically isolated into a question counting arrangement layer and a trusted core layer, comprising: The input interaction module deployed in the question orchestration layer is used to receive natural language question requests input by the user; The intelligent agent orchestration module deployed in the question number orchestration layer is used to query the saved historical context and merge the natural language question number request with the historical context through a multi-turn dialogue context. The semantic processing module deployed in the question number orchestration layer is used to perform word segmentation and normalization on the merged requests, extract business original words, and generate pure business semantic payloads. The knowledge governance module deployed in the question number orchestration layer contains a governed semantic asset knowledge base, which is used to initiate a recall request to the semantic asset knowledge base based on the pure business semantic payload to obtain semantic slices; The semantic parsing module deployed in the trusted core layer is used to perform deterministic candidate parsing on the pure business semantic payload, return the structured parsing result, and converge with the semantic slice to obtain semantic asset candidates; The domain-specific language construction module deployed in the question number orchestration layer is used to dynamically generate controlled query plan instructions based on the semantic asset candidates. The controlled query plan instructions are an intermediate representation that is completely decoupled from user input and maintained by the system itself, used to encapsulate the query data source, indicator mapping, filtering conditions, business time range and return format. The trusted execution module, deployed in the trusted core layer, is used to parse the controlled query plan instruction, translate the controlled query plan instruction into at least one parameterized SQL based on the governed semantic assets and the verification of the effective status of the semantic assets, and perform dimensional and metric-level effective status verification on the at least one parameterized SQL. After the verification passes, the at least one parameterized SQL is executed to obtain data results; and based on the data results, combined with the governed semantic assets and business rules, an encapsulated trusted data package is generated. The result expression module, deployed in the question number orchestration layer, is used to generate an answer based on the trusted data packet and return it to the user.

Images