A method and system for staged refinement of natural language query abcs

Abstract

This application provides a phased precision transformation method and system for Natural Language Query ABC. The phased precision transformation method includes the following steps: Step A identifies the object classes involved in the user's question based on the object class and relation class definitions of the ontology model layer and constructs an edge list of the object relation subgraph; Step B is executed in two phases sequentially: the first phase reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, tracing the source of each condition through condition source annotation; the second phase determines the extraction fields of each object class according to the user's information requirements; Step C determines the calculation logic; and the outputs of Steps A, B, and C are assembled into an OQS intermediate representation using a node-edge separated JSON format. In the above technical solution, a standardized query decomposition method is established, and the probability of query illusion is reduced.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and natural language processing technology, and in particular to a method and system for phased and precise conversion of natural language query ABC. Background Technology

[0002] Transforming natural language into data query commands (such as Text-to-SQL, Text-to-DSL, etc.) using large language models is a core requirement for enterprise-level AI applications. However, in practical engineering, this type of technology faces the following prominent problems:

[0003] 1. The "semantic gap" when large language models directly generate query commands leads to frequent illusions:

[0004] Existing Text-to-SQL solutions attempt to enable large language models to complete the cross-layer transformation from natural language to underlying query code in a single inference. However, a significant semantic gap exists between business concepts in natural language (such as "sales revenue," "mentor," and "honors") and the physical structure of the underlying data system (such as table names, field names, and relational paths). Large language models need to simultaneously perform multiple cognitive tasks, including business semantic understanding, business logic construction, conditional reasoning, and code generation. This excessive cognitive load makes them prone to illusions such as field fabrication and incorrect relational paths, resulting in low usability of generated query commands in production environments.

[0005] 2. Lack of standardized task decomposition methodology for graph-structured queries:

[0006] In complex query scenarios involving multiple business objects and their relationships (such as "finding a list of customers with after-sales complaints in orders for finished products made from raw materials supplied by supplier A"), the query task naturally exhibits graph structure characteristics. In recent years, academia has proposed various query decomposition strategies, but these solutions lack a theoretically complete decomposition methodology for graph-structured data such as ontology semantic networks. This results in large language models lacking stable reasoning paradigms when facing complex topologies such as chains, trees, and networks, and the quality of the output queries drops sharply with the complexity of the problem.

[0007] 3. The intermediate representation of graph structures is not suitable for processing large language models:

[0008] In scenarios requiring descriptions of object relationship subgraphs, if adjacency matrix representation is used, its token consumption increases by O(n²) with the number of nodes, and the large number of "unrelated" null values ​​in the sparse matrix can distract the attention of large language models. More critically, the cells of the adjacency matrix can only express "whether a relationship exists," and cannot naturally carry the filtering conditions, extracted fields, and other attribute information on the nodes, resulting in the inability to efficiently integrate the graph's topology and node attributes in a unified representation.

[0009] 4. The expression of query intent is too tightly coupled with the generation of underlying execution instructions:

[0010] In existing solutions, two fundamentally different tasks—"understanding what the user wants to query" and "generating the underlying query code"—are mixed in the same reasoning process. This leads to two problems: firstly, when the underlying data engine changes, the entire query generation logic needs to be rewritten; secondly, the intermediate reasoning process is untraceable and unexplainable, making it difficult to meet enterprise-level auditing requirements. There is a lack of an intermediate representation layer that is independent of the underlying execution engine and purely describes the semantic intent of the query.

[0011] 5. The value of ontology semantic constraints in query generation is not being utilized by the system:

[0012] Ontology Semantic Data Network (ONN) provides high-level semantic structure definitions (object classes, relation classes, constraint rules) for data and business, but existing LLM solutions do not systematically use these constraints as the driving force for query decomposition and generation. This leads to a lack of constraints in object recognition of large language models (easy to create objects), a lack of business rule injection in condition processing (relying only on explicit user conditions), and a lack of theoretical necessity in decomposition steps (arbitrary decomposition methods, lack of proof). Summary of the Invention

[0013] This application provides a phased precision transformation method and system for natural language query ABC, which is used to establish a standardized query decomposition method and reduce the probability of illusion.

[0014] Firstly, a phased refinement method for natural language query ABC is provided, including the following steps:

[0015] Step A identifies the object classes involved in the user's question based on the object class definition and relation class definition of the ontology model layer and constructs an edge list of the object relation subgraph;

[0016] Step B is executed in two phases. The first phase reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, and traces the source of each condition through the condition source annotation. The second phase determines the extraction fields of each object class according to the user's information requirements.

[0017] Step C determines the computational logic;

[0018] The outputs of steps A, B, and C are assembled into an OQS intermediate representation using a node-edge separated JSON format.

[0019] In the above technical solution, Step A identifies the object classes involved in the user's question based on the object class definition and relation class definition of the ontology model layer and constructs an edge list of the object relation subgraph; Step B is executed in two stages: the first stage reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, and traces the source of each condition through condition source annotation; the second stage determines the extraction fields of each object class according to the user's information requirements; Step C determines the calculation logic; the outputs of Steps A, B and C are assembled into an OQS intermediate representation using a node-edge separated JSON format; a standardized query decomposition method is established, and the probability of illusion is reduced.

[0020] In a specific feasible implementation, the necessary order of steps A, B, and C is as follows:

[0021] The output of step A is a necessary input for step B. The field determination in the second stage of step B can only proceed after the conditions in the first stage of step B are clear. The fields determined in the second stage of step B are necessary for defining the calculation formula in step C.

[0022] In one specific implementation, the object class identification in step A is constrained by the ONN ontology model layer, and only object classes defined in the ontology model layer are identified.

[0023] In a specific feasible implementation, when adding filtering conditions to each object class in the first stage of step B, the conditions explicitly proposed by the user and the business default rules defined in the CBC constraint pattern in the ontology model layer are processed simultaneously to perform system integration of user conditions and business rules, and the source of each filtering condition is marked.

[0024] In a specific feasible implementation, the node part of OQS corresponds to the object class definition of the ontology, the edge part directly corresponds to the relation class definition of the ontology, and the node selection conditions come from the CBC constraints of the ontology, making the data structure of OQS a necessary mapping of the ontology model layer structure.

[0025] In a specific feasible implementation, the semantic subgraph constructed in step A is expressed in the form of an edge list to support chain, tree, star, and mesh directed graph topologies. The processing logic of the ABC paradigm for each topology remains consistent across all topologies.

[0026] In a specific feasible implementation, the ABC paradigm includes a query planning agent, a condition filtering agent, a field extraction agent, and a calculation method agent, wherein,

[0027] The query planning agent, condition filtering agent, field extraction agent, and calculation method agent work together in a serial pipeline manner.

[0028] In one specific implementation scheme, it also includes:

[0029] Translate OQS into a pipelined DSL that can be executed by the underlying data engine.

[0030] Secondly, a phased precision transformation system for natural language query ABC is provided, including:

[0031] The query planning module is used to identify object classes and construct an edge list based on the ontology model layer;

[0032] The condition filtering module is used to inject business rules and user conditions from ontology CBC constraints and mark their sources;

[0033] The field extraction module is used to determine the fields to be extracted for each object class based on user requirements.

[0034] The calculation method module is used to determine the calculation logic;

[0035] The OQS assembly module is used to assemble the outputs of the query planning module, the condition filtering module, the field extraction module, and the calculation method module into a node-edge separated structured intermediate representation.

[0036] In the above technical solution, Step A identifies the object classes involved in the user's question based on the object class definition and relation class definition of the ontology model layer and constructs an edge list of the object relation subgraph; Step B is executed in two stages: the first stage reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, and traces the source of each condition through condition source annotation; the second stage determines the extraction fields of each object class according to the user's information requirements; Step C determines the calculation logic; the outputs of Steps A, B and C are assembled into an OQS intermediate representation using a node-edge separated JSON format; a standardized query decomposition method is established, and the probability of illusion is reduced.

[0037] In one specific implementation scheme, it also includes:

[0038] The DSL mapping module is used to translate OQS into executable instructions. Attached Figure Description

[0039] Figure 1 A flowchart illustrating the phased precision transformation method for natural language query ABC provided in this application embodiment;

[0040] Figure 2 The structural block diagram of the phased precision conversion system for natural language query ABC provided in the embodiments of this application is shown. Detailed Implementation

[0041] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. Through these descriptions, the features and advantages of the present application will become clearer and more apparent.

[0042] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0043] Furthermore, the technical features involved in the different embodiments of this application described below can be combined with each other as long as they do not conflict with each other. The following detailed description, in conjunction with specific accompanying drawings, illustrates the embodiments.

[0044] In order to accurately define the technical scope of this application, the core terms are defined and explained as follows:

[0045] The ABC paradigm (Acquire-Build-Calculate) is a methodology for breaking down complex natural language queries into three standardized operational steps. Step A (Acquire Objects) identifies the business object classes involved in the user's question and constructs an object relationship subgraph based on the ontology model layer definition. Step B (Build Dataset) consists of two phases: the first phase determines the filtering conditions (including explicit user conditions and default business rules) for each object class in the subgraph, and the second phase determines the specific data fields to be extracted from each object instance. Step C (Calculate Metrics) determines the calculation logic, such as aggregation functions, sorting rules, and ratio formulas, based on the extracted fields.

[0046] ONN Query Specification (OQS): A structured intermediate representation output from a multi-agent collaborative process using the ABC paradigm. OQS describes query intent using a node-edge separated JSON format. The nodes record the filtering conditions and extracted fields for each object class, the edges record the relationship types and directions between object classes, and the metrics record the calculation formulas between fields. OQS carries all the semantic information from the ABC steps, serving as an intermediate bridge connecting the natural language semantic world and the underlying execution engine.

[0047] Ontology Semantic Data Network (ONN): A computable semantic network data structure with ontologies as nodes, semantic relations as edges, and CBC (Context-Behavior-Constraint) as the unified logical kernel. This network comprises an ontology model layer (defining object classes, relation classes, and their CBC patterns), an instance network layer (storing specific instance data and inheriting the CBC patterns from the model layer), and a behavior implementation layer (associating semantic behaviors with program code, API calls, or agent workflows). In this invention, the ONN's ontology model layer provides object class definitions and relation topology knowledge for step A of the ABC paradigm and provides default business rules for step B. The term "network" specifically refers to the semantic graph topology structure composed of ontology classes, relation classes, instance nodes, and their attributes, rather than a deep learning parameterized model based on artificial neuron weights and backpropagation algorithms.

[0048] Pipeline DSL (Domain Specific Language): A set of executable instructions for a low-level engine that is translated from OQS by a DSL-generated agent. It uses JSON format and supports multi-step chained computation. The translation from OQS to Pipeline DSL follows deterministic mapping rules, rather than relying on probabilistic reasoning from a large language model.

[0049] Node-Edge Separated Structure: A graph structure representation method that describes the node information (object class, filtering conditions, extraction fields) and edge information (relationship type, direction) of the graph using independent data structures, instead of using a two-dimensional matrix representation of the adjacency matrix. This structure has a storage space complexity of O(n+e) (where n is the number of nodes and e is the number of edges), significantly reducing the token consumption required for processing large language models compared to the O(n²) of the adjacency matrix.

[0050] Condition Source Annotation (CSA): A mechanism that records both the condition value and its source in the filtering criteria. The source of each filtering condition is annotated as either "User Question" (explicitly raised by the user) or "Business Default Rule" (automatically injected by CBC constraints in the ontology model layer), making the ontology-driven condition injection process fully traceable and auditable.

[0051] exist Figure 1 This application provides a method for phased precision transformation of natural language query ABC, including the following steps:

[0052] Step A identifies the object classes involved in the user's question based on the object class definition and relation class definition of the ontology model layer and constructs an edge list of the object relation subgraph;

[0053] Step B is executed in two phases. The first phase reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, and traces the source of each condition through the condition source annotation. The second phase determines the extraction fields of each object class according to the user's information requirements.

[0054] Step C determines the computational logic;

[0055] The outputs of steps A, B, and C are assembled into an OQS intermediate representation using a node-edge separated JSON format.

[0056] In the above technical solution, Step A identifies the object classes involved in the user's question based on the object class definition and relation class definition of the ontology model layer and constructs an edge list of the object relation subgraph; Step B is executed in two stages: the first stage reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, and traces the source of each condition through condition source annotation; the second stage determines the extraction fields of each object class according to the user's information requirements; Step C determines the calculation logic; the outputs of Steps A, B and C are assembled into an OQS intermediate representation using a node-edge separated JSON format; a standardized query decomposition method is established, and the probability of illusion is reduced.

[0057] Specifically, the beneficial effects include:

[0058] Standardized query decomposition methodologies significantly reduce the probability of illusions. The ABC paradigm breaks down the single-hop, high-difficulty transformation from "natural language to query code" into a multi-step, low-difficulty transformation from A to B to C to OQS to DSL. The cognitive load at each step is controllable, and the large language model only needs to focus on one dimension of the reasoning task.

[0059] The node-edge separated intermediate representation of OQS efficiently adapts to large language models. Compared to the O(n²) token consumption of the adjacency matrix, OQS only has O(n+e) cost, and each node has high cohesion, perfectly matching the serialization processing characteristics of large language models. This structure naturally supports various graph topologies.

[0060] The semantic intent of the query is decoupled from the underlying execution instructions. OQS, as an intermediate representation of the pure semantic layer, is independent of any underlying data engine. When the underlying engine changes, only the mapping rules for the Agent generated by the DSL need to be modified.

[0061] A deterministic multi-agent serial pipeline ensures output quality. Four dedicated agents execute strictly in the serial order A→B1→B2→C. Compared to autonomous negotiation-based multi-agent schemes, the deterministic pipeline avoids responsibility overstepping and information loss.

[0062] The entire process is traceable and meets the requirements for interpretability. Each step is recorded in a structured format, forming a complete chain of reasoning evidence.

[0063] Source labeling for criteria supports business rule governance. Each filter criterion in OQS is labeled with its source, supporting compliance verification and quality inspection analysis.

[0064] Ontology constraints give ABC decomposition theoretical necessity and completeness. The object class identification in step A is constrained by the ontology definition (avoiding arbitrary creation), the condition injection in step B is driven by the ontology CBC constraints (ensuring no business rules are omitted), and the OQS structure is a necessary mapping of the ontology structure. The ABC decomposition method is not arbitrarily designed, but determined by the ontology structure.

[0065] In a specific feasible implementation, the necessary order of steps A, B, and C is as follows:

[0066] The output of step A is a necessary input for step B. The field determination in the second stage of step B can only proceed after the conditions in the first stage of step B are clear. The fields determined in the second stage of step B are necessary for defining the calculation formula in step C.

[0067] In one specific implementation, the object class identification in step A is constrained by the ONN ontology model layer, and only object classes defined in the ontology model layer are identified.

[0068] In a specific feasible implementation, when adding filtering conditions to each object class in the first stage of step B, the conditions explicitly proposed by the user and the business default rules defined in the CBC constraint pattern in the ontology model layer are processed simultaneously to perform system integration of user conditions and business rules, and the source of each filtering condition is marked.

[0069] In a specific feasible implementation, the node part of OQS corresponds to the object class definition of the ontology, the edge part directly corresponds to the relation class definition of the ontology, and the node selection conditions come from the CBC constraints of the ontology, making the data structure of OQS a necessary mapping of the ontology model layer structure.

[0070] In a specific feasible implementation, the semantic subgraph constructed in step A is expressed in the form of an edge list to support chain, tree, star, and mesh directed graph topologies. The processing logic of the ABC paradigm for each topology remains consistent across all topologies.

[0071] In a specific feasible implementation, the ABC paradigm includes a query planning agent, a condition filtering agent, a field extraction agent, and a calculation method agent, wherein,

[0072] The query planning agent, condition filtering agent, field extraction agent, and calculation method agent work together in a serial pipeline manner.

[0073] In one specific implementation scheme, it also includes:

[0074] Translate OQS into a pipelined DSL that can be executed by the underlying data engine.

[0075] In one specific implementation scheme, the phased precision transformation method for natural language query ABC includes the following steps:

[0076] Step 1: Step A – Query Planning Agent constructs semantic subgraph

[0077] The Query Planning Agent receives the user's natural language query after intent clarification and verification, and performs the following operations based on the object class and relation class definitions in the ONN ontology model layer:

[0078] (a) Object Class Identification. Identify the relevant business object classes from user questions. The identification process is constrained by the ONN model layer—only object classes defined in the ONN model layer are identified, and non-existent object classes are not created.

[0079] (b) Topology Construction. Based on the predefined relation class definitions in the ONN model layer (including the starting object class, the target object class, and the relation identifier), the relation paths between the identified object classes are determined, and a semantic subgraph is constructed. The subgraph is expressed in the form of an edge list, with each edge recording the source node identifier, the target node identifier, and the relation type.

[0080] (c) Subgraph topology adaptation. The edge list can express various graph structures such as chain topology (e.g., A→B→C), tree topology (e.g., A→B, A→C, A→D), star topology (e.g., B→A, C→A, D→A), and network topology (e.g., A→B→D, A→C→D).

[0081] The output of this step is: a list of identified object classes (identifier and classpath of each object class) and a list of edges (source node, target node, and relation type of each relation).

[0082] Proof of the necessity of step A: The ontology model layer defines which are "business object classes," and the semantic entities in the user's question must be mapped to these object classes. If step A is skipped, subsequent steps cannot determine "on which objects to operate on." The output of A (list of object classes + list of edges) is a necessary input for B and C, and the accuracy of A directly affects the accuracy of all subsequent steps (source control).

[0083] Step Two: Step B, Phase One – Conditional Filtering: The Agent adds filtering conditions to each object class.

[0084] The conditional filtering agent receives the list of object classes and edge lists output from step one, analyzes each object class in the subgraph, and applies filtering conditions accordingly:

[0085] (a) Extraction of explicit user constraints. Extract explicit constraints for each object class from the user's natural language question.

[0086] (b) Injection of business default rules. Read the predefined CBC constraint patterns (Constraint part) for each object class in the ONN model layer and automatically inject the business default rules therein as filtering conditions.

[0087] (c) Source labeling of conditions. Label the source of each filter condition, distinguishing between "user issues" or "business default rules" to support subsequent interpretability traceability and quality inspection verification.

[0088] The output of this step is: a list of filter criteria for each object class, with each criterion including a field name, operator, comparison value, and criterion source.

[0089] The necessity of step B1 is proven by the fact that the CBC constraint pattern of the ontology defines the business rules for each object class, and the explicit conditions in the user's question must be integrated with these business rules. B1 not only deals with "what the user explicitly said," but also with "what rules the ontology implicitly defines." This integration of "user conditions + business rules" is completely lacking in existing LLM solutions.

[0090] Step 3: Step B, Second Stage – Field Extraction The Agent determines the fields to be extracted for each object class.

[0091] The field extraction agent receives the outputs from steps one and two, and determines the specific attribute fields to be extracted from each object instance based on the information requirements expressed in the user's question:

[0092] (a) Analyze the information that users want to see and map the information requirements to specific object class attribute fields.

[0093] (b) Allowing some object classes to have no fields extracted. In a subgraph, some object classes may only serve as intermediate nodes or filter anchors in the relational path, and users do not need their attribute data. In such cases, the list of fields to extract for these object classes should be empty.

[0094] The output of this step is a list of extracted fields for each object class.

[0095] Proof of the necessity of step B2: B2 must be executed after A (knowing the object class is necessary to determine its fields); B2 must be executed before C (the fields are necessary to determine how to calculate).

[0096] Step Four: Step C – Calculation Method: Agent determines the calculation logic

[0097] The computational method agent receives all the outputs from steps one through three and analyzes the implicit or explicit computational requirements in the user's problem:

[0098] (a) If the user's question involves calculation logic such as aggregation calculation (e.g., summation, counting, average), sorting rules, ratio formulas, group statistics, etc., then determine the specific calculation formula and refer to the extracted field determined in step three in the form of "alias.field name".

[0099] (b) If the user's question is a detailed query (not involving calculation), then mark that there is no calculation requirement for this query and output it as a detailed wide table.

[0100] The output of this step is: a list of calculation formulas (if any) or a "No calculation required" label.

[0101] Proof that the order of A→B1→B2→C cannot be changed: A→B1: B1 needs the object class identified by A to determine "who to apply the condition to"; B1→B2: Field extraction requires clear conditions to determine "which fields are valid"; B2→C: The calculation formula requires known fields to define. Reversing or changing the order will lead to missing information or disordered reasoning.

[0102] Step 5: Assemble the OQS – Combine the outputs of steps ABC into a structured intermediate representation.

[0103] The outputs from steps one through four are assembled into a complete OQS. The OQS uses a node-edge separated JSON structured format and comprises the following three parts:

[0104] (a) Nodes. An ordered array, each element of which describes an object class. Each node contains: node identifier (id), object class name (class), classpath identifier (class_path), filter list (filters, from step two), and extract field list (extract_fields, from step three).

[0105] (b) Edges. An ordered array, each element describing a relation. Each edge contains: source node identifier (from), target node identifier (to), and relation type (type).

[0106] (c) Metrics (if any). Describe the calculation logic determined in step four, including: calculation expression (expr), grouping field (group_by), post-filter conditions (post_filter), etc.

[0107] The choice of OQS to use a node-edge separation structure instead of an adjacency matrix is ​​based on the following considerations:

[0108] First, the storage space of the adjacency matrix increases by O(n²) with the number of nodes, while the node-edge separation representation is only O(n+e), which significantly reduces the token consumption required for processing large language models.

[0109] Secondly, the attention mechanism of large language models is better at handling serialization and tree structures, and its accuracy in understanding the path description method of "source node-relationship-target node" is significantly better than the random access understanding of sparse two-dimensional matrices.

[0110] Third, the node-edge separation structure naturally supports attaching filtering conditions and extraction fields to nodes, achieving decoupling of topology and attribute information, with each node becoming a highly cohesive self-describing unit.

[0111] The necessity of mapping ontology to OQS: OQS is not an arbitrary intermediate representation design, but rather a necessary result derived from the semantic structure of the ontology. The set of object class definitions in the ontology model layer is directly mapped to the node structure of OQS, the set of relation class definitions is directly mapped to the edge structure of OQS, and the CBC constraint pattern is directly mapped to the filters of OQS nodes. Therefore, the data structure of OQS is uniquely determined under ABC processing.

[0112] Step Six: The DSL generates an agent that translates the OQS mapping into a pipelined DSL.

[0113] The DSL generation agent reads the OQS and translates it into a pipelined DSL executable by the underlying data engine according to the following deterministic mapping rules:

[0114] (a) The edge list in OQS is transformed into a graph pattern matching clause in DSL.

[0115] (b) The filtering conditions of each node in OQS are transformed into the Conditions clause in DSL.

[0116] (c) The extracted fields of each node in OQS are converted into the Output Fields clause in DSL.

[0117] (d) The calculation formulas in OQS are converted into pipeline steps in DSL, supporting multi-step chain execution.

[0118] In one specific implementation, the ABC paradigm of this invention is executed collaboratively by four dedicated agents in a strict sequential order:

[0119] Agent 1: Query Planning Agent (corresponding to step A) – Input: User natural language query + ONN ontology model layer definition. Responsibilities: Identify the object classes involved and construct an edge list of the semantic subgraph. Output: List of object classes + list of edges.

[0120] Agent 2: Condition Filtering Agent (corresponding to the first stage of step B) – Input: Output of Agent 1 + CBC constraint definition of the ONN ontology model layer. Responsibilities: Attach filtering conditions (explicit user conditions + default business rules) to each object class, and indicate the source of the conditions. Output: A list of filtering conditions for each object class.

[0121] Agent 3: Field Extraction Agent (corresponding to Step B, Phase 2) – Input: Outputs of Agent 1 and Agent 2 + User question. Responsibility: Determine the extraction fields for each object class based on the user's information requirements. Output: List of extraction fields for each object class.

[0122] Agent 4: Computation Method Agent (corresponding to step C) – Input: All outputs from Agents 1 to 3 + user question. Responsibilities: Determine the computational logic for aggregation, sorting, ratios, etc. Output: Calculation formula (or marked "No computational requirement"). The necessity of the four-agent division:

[0123] There cannot be three agents (one each of A, B, and C): Step B involves two fundamentally different cognitive tasks—B1 matches ontology constraints to determine "what to filter," and B2 matches user needs to determine "what data to extract." These two tasks rely on completely different contexts, and forcing them to be completed in a single agent will lead to inference conflicts.

[0124] There cannot be five or more agents: each additional agent increases the complexity of the collaboration without increasing the theoretical completeness.

[0125] Therefore, the four agents (corresponding to A, B1, B2, and C) represent the optimal balance between theoretical completeness and implementation feasibility.

[0126] Example 1: Detailed query (star topology) includes:

[0127] Scenario: University research management system. The ONN model layer has defined object classes and their relationships, including papers, master's students, faculty and staff, organizational structures, records of changes in professional titles, and talent honors and achievements.

[0128] User question: "Find papers in the field of artificial intelligence, including the authors, supervisors, their institutions, and honors received." Step A—Query the output of the planning agent:

[0129] Six object classes were identified, and a semantic subgraph was constructed. The edge list is shown in Table 1, which describes a star topology centered on "faculty and staff".

[0130]

[0131] Table 1. Edge list of Implementation Example 1

[0132] The output of Step B, Phase 1 – Conditional Filtering Agent is shown in Table 2:

[0133]

[0134] Table 2 Output table of the conditional filtering agent in Example 1

[0135] Step B, second stage – Field Extraction: The output of the Agent is shown in Table 3.

[0136]

[0137] Table 3 Output table of the conditional filtering agent in Example 1

[0138] Step C – Calculate the output of the Agent method:

[0139] This query does not require complex aggregation calculations and outputs results in a detailed wide table. The assembled OQS (JSON format) is as follows:

[0140] {

[0141] "nodes": [

[0142] {"id": "n1", "class": "paper", "class_path": " / univ_demo / paper",

[0143] "filters": [{"field": "keywords", "op": "like", "value": "%Artificial Intelligence%", "source": "User Issues"}],

[0144] "extract_fields": ["title", "abstract", "keywords", "journals","level", "type"]},

[0145] {"id": "n2", "class": "Master's Degree", "class_path": " / univ_demo / student_master",

[0146] "filters": [], "extract_fields": ["name"]},

[0147] {"id": "n3", "class": "faculty and staff", "class_path": " / univ_demo / person",

[0148] "filters": [{"field": "status", "op": "=", "value": "On-the-job", "source": "Default business rules"}],

[0149] "extract_fields": ["name"]},

[0150] {"id": "n4", "class": "Organization", "class_path": " / univ_demo / org",

[0151] "filters": [], "extract_fields": ["name"]},

[0152] {"id": "n5", "class": "Professional Title Change Record", "class_path": " / univ_demo / tech_duty",

[0153] "filters": [{"field": "last_flag", "op": "=", "value": "is", "source": "default business rule"}],

[0154] "extract_fields": ["duty", "duty_level"]},

[0155] {"id": "n6", "class": "Talent Honors and Achievements", "class_path": " / univ_demo / szxxsb",

[0156] "filters": [{"field": "gccrc", "op": "in", "value": ["National-level Talent Category A","National-level Talent Category B","National-level Talent Category C","Provincial / Ministerial-level Talent","University-level Talent"], "source": "Business Default Rules"}],

[0157] "extract_fields": ["xm_name", "gccrc"]}

[0158] ],

[0159] "edges": [

[0160] {"from": "n2", "to": "n1", "type": "own_paper"},

[0161] {"from": "n3", "to": "n2", "type": "person_to_master"},

[0162] {"from": "n3", "to": "n4", "type": "person_to_org"},

[0163] {"from": "n3", "to": "n5", "type": "person_to_tech_duty"},

[0164] {"from": "n3", "to": "n6", "type": "person_to_szxxsb"}

[0165] ],

[0166] "metrics": null

[0167] }

[0168] Example 2: Chained queries involving aggregation calculations include:

[0169] Scenario: Supply chain management system. The ONN model layer has defined object classes such as supplier, raw material batch, finished product batch, and order, as well as their relationships.

[0170] User Question: "Calculate the total sales order amount of finished products made from raw materials supplied by each supplier in 2024, and sort them in descending order of amount." Step A - Query the output of the planning agent:

[0171] Four object classes were identified, and a chain topology was constructed: Supplier (n1) → Raw material batch (n2) → Finished product batch (n3) → Order (n4).

[0172] The output of Step B, Phase 1 – Conditional Filtering Agent is shown in Table 4:

[0173]

[0174] Table 4 Output table of the conditional filtering agent in Example 2

[0175] Step B, Second Stage – Field Extraction: Output of the Agent

[0176] Extract the name from the supplier; do not extract the raw material batch (it is only used as a path node); do not extract the finished product batch; extract the amount from the order.

[0177] Step C – The output of the Agent calculation method is:

[0178] {

[0179] "expr": "SUM(n4.amount)",

[0180] "group_by": ["n1.name"],

[0181] "order_by": [{"field": "SUM(n4.amount)", "direction": "DESC"}]

[0182] }

[0183] Assemble OQS (JSON format) as follows:

[0184] {

[0185] "nodes": [

[0186] {"id": "n1", "class": "supplier", "filters": [], "extract_fields":["name"]},

[0187] {"id": "n2", "class": "Raw material batch",

[0188] "filters": [{"field": "supply_date", "op": "between", "value": ["2024-01-01", "2024-12-31"], "source": "User question"}],

[0189] "extract_fields": []},

[0190] {"id": "n3", "class": "Finished product batch", "filters": [], "extract_fields": []},

[0191] {"id": "n4", "class": "Order", "filters": [], "extract_fields": ["amount"]}

[0192] ,

[0193] "edges":

[0194] {"from": "n1", "to": "n2", "type": "supply"},

[0195] {"from": "n2", "to": "n3", "type": "produce"},

[0196] {"from": "n3", "to": "n4", "type": "sell"}

[0197] ,

[0198] "metrics": {

[0199] "expr": "SUM(n4.amount)",

[0200] "group_by": ["n1.name"],

[0201] "order_by": [{"field": "SUM(n4.amount)", "direction": "DESC"}]

[0202] }

[0203] }

[0204] This example demonstrates the ability of the ABC paradigm to handle chained topologies, scenarios where intermediate nodes do not extract fields (only serving as path constraints), and the ability of the C step to handle aggregation calculation requirements.

[0205] Example 3: The process of chained + branched query involving multimodal conditions includes:

[0206] Scenario: Food safety traceability system. The ONN model layer has defined object classes such as supplier, raw material batch, finished product batch, order, customer, and after-sales feedback.

[0207] User question: "Find the orders for finished products made from raw material batches supplied by supplier A in September 2025, whether 'taste' was mentioned in the after-sales feedback, and provide a list of affected customers and order amounts." Step A identifies 6 object classes and constructs a "chain + branch" topology: Supplier → Raw material batch → Finished product batch → Order is the main chain, and the orders are connected to customers and after-sales feedback to form branches.

[0208] Step B, first stage of conditional screening: Supplier name='Supplier A' (user issue); Raw material batch supply_date range 2025-09 (user issue); After-sales feedback content contains 'taste' (user issue, text modal).

[0209] Step B, second stage: field extraction: extract amount from orders, extract name from customers, and extract content from after-sales feedback.

[0210] This example demonstrates the ABC paradigm's ability to handle chained and branched topologies, its ability to handle multimodal conditions, and scenarios where multiple intermediate nodes do not extract fields.

[0211] The ABC adaptability analysis for various graph topologies includes: for any directed graph topology G=(V,E), where V is the set of object classes defined by the ontology, and E is the set of relation classes defined by the ontology:

[0212] Step A: Topology-driven – Requires understanding the topological shape, but only needs to correctly map ontological relationships. Adapts to all topologies.

[0213] Step B: Node-driven – Each node processes independently, completely independent of the topological location of other nodes.

[0214] C-step: Field-driven – Calculations are based on defined field definitions, without considering topological shape.

[0215] Therefore, regardless of whether it is a chain, tree, star, or complex mesh topology, the ABC processing method is logically consistent.

[0216] Taking the 6 object classes and 5 relations in Example 1 as an example: the comparison and analysis of the node-edge separation structure of OQS and the adjacency matrix is ​​shown in Table 5.

[0217]

[0218] Table 5 Comparison and Analysis of Node-Edge Separation Structure and Adjacency Matrix in OQS

[0219] Table 6 shows a comparative analysis with existing technologies.

[0220]

[0221] Table 6 Comparative Analysis with Existing Technologies

[0222] The beneficial effects of the above technical solution include:

[0223] Query accuracy is significantly improved. By breaking down the single-hop transformation from "natural language to query code" into multi-step transformations, the task complexity of the large language model at each step is greatly reduced. In complex queries involving 6 object classes and 5 relationships, the system can accurately identify all object classes and relationship paths and correctly inject business default rules.

[0224] It supports multiple graph topologies. OQS successfully handled various topologies such as star topology (Example 1), chain topology (Example 2), and chain + branch topology (Example 3).

[0225] Token consumption is controllable. In a 6-node, 5-edge scenario, OQS's token consumption is only about 30% of that of the adjacency matrix.

[0226] The entire process is traceable. The results of each step are recorded in structured JSON format, forming a complete chain of reasoning evidence.

[0227] exist Figure 2 In this application, embodiments provide a phased precision conversion system for natural language query ABC, including:

[0228] The query planning module is used to identify object classes and construct an edge list based on the ontology model layer;

[0229] The condition filtering module is used to inject business rules and user conditions from ontology CBC constraints and mark their sources;

[0230] The field extraction module is used to determine the fields to be extracted for each object class based on user requirements.

[0231] The calculation method module is used to determine the calculation logic;

[0232] The OQS assembly module is used to assemble the outputs of the query planning module, the condition filtering module, the field extraction module, and the calculation method module into a node-edge separated structured intermediate representation.

[0233] In the above technical solution, Step A identifies the object classes involved in the user's question based on the object class definition and relation class definition of the ontology model layer and constructs an edge list of the object relation subgraph; Step B is executed in two stages: the first stage reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, and traces the source of each condition through condition source annotation; the second stage determines the extraction fields of each object class according to the user's information requirements; Step C determines the calculation logic; the outputs of Steps A, B and C are assembled into an OQS intermediate representation using a node-edge separated JSON format; a standardized query decomposition method is established, and the probability of illusion is reduced.

[0234] In one specific implementation scheme, it also includes:

[0235] The DSL mapping module is used to translate OQS into executable instructions.

[0236] Those skilled in the art will know that this application can be implemented as a system, method, or computer program product.

[0237] Therefore, this disclosure can be implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this application can also be implemented as a computer program product in one or more computer-readable media, the computer-readable media containing computer-readable program code.

[0238] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0239] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application. Based on this, various substitutions and improvements can be made to this application, all of which fall within the protection scope of this application.

Claims

1. A phased precision transformation method for natural language query ABC, characterized in that, Includes the following steps: Step A identifies the object classes involved in the user's question based on the object class definition and relation class definition of the ontology model layer, and constructs an edge list of the object relation subgraph; Step B is executed in two phases. The first phase reads the business default rules from the CBC constraint pattern of the ontology and merges them with the user's explicit conditions, and traces the source of each condition through the condition source annotation. The second phase determines the extraction fields of each object class according to the user's information requirements. Step C determines the computational logic; The outputs of steps A, B, and C are assembled into an OQS intermediate representation using a node-edge separated JSON format.

2. The phased precision transformation method for natural language query ABC according to claim 1, characterized in that, The necessity of the order of steps A, B, and C is as follows: The output of step A is a necessary input for step B. The field determination in the second stage of step B can only proceed after the conditions in the first stage of step B are clear. The fields determined in the second stage of step B are necessary for defining the calculation formula in step C.

3. The phased precision transformation method for natural language query ABC according to claim 2, characterized in that, The object class identification in step A is constrained by the ONN ontology model layer, and only identifies object classes that have been defined in the ontology model layer.

4. The phased precision transformation method for natural language query ABC according to claim 3, characterized in that, In the first stage of step B, when adding filtering conditions to each object class, the conditions explicitly proposed by the user and the business default rules defined in the CBC constraint pattern in the ontology model layer are processed simultaneously. The system integrates user conditions and business rules, and the source of each filtering condition is marked.

5. The phased precision transformation method for natural language query ABC according to claim 4, characterized in that, In OQS, the node part corresponds to the object class definition of the ontology, the edge part directly corresponds to the relation class definition of the ontology, and the node selection criteria come from the CBC constraints of the ontology, making the data structure of OQS a necessary mapping of the ontology model layer structure.

6. The phased precision transformation method for natural language query ABC according to claim 5, characterized in that, The semantic subgraph constructed in step A is expressed in the form of an edge list, which is used to support chain, tree, star, and network directed graph topologies. The processing logic of the ABC paradigm for each topology remains consistent across all topologies.

7. The phased precision transformation method for natural language query ABC according to claim 6, characterized in that, The ABC paradigm includes a query planning agent, a condition filtering agent, a field extraction agent, and a calculation method agent. The query planning agent, condition filtering agent, field extraction agent, and calculation method agent work together in a serial pipeline manner.

8. The phased precision transformation method for natural language query ABC according to claim 7, characterized in that, Also includes: Translate OQS into a pipelined DSL that can be executed by the underlying data engine.

9. A system for staged precision conversion of natural language query ABC based on the staged precision conversion method of any one of claims 1-8, characterized in that, include: The query planning module is used to identify object classes and construct an edge list based on the ontology model layer; The condition filtering module is used to inject business rules and user conditions from ontology CBC constraints and mark their sources; The field extraction module is used to determine the fields to be extracted for each object class based on user requirements. The calculation method module is used to determine the calculation logic; The OQS assembly module is used to assemble the outputs of the query planning module, the condition filtering module, the field extraction module, and the calculation method module into a node-edge separated structured intermediate representation.

10. The phased precision conversion system for natural language query ABC according to claim 9, characterized in that, Also includes: The DSL mapping module is used to translate OQS into executable instructions.

Images