A hybrid query language translation method and system based on description logic and graph query fusion
Patent Information
- Application Number
- CN202610316588.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2026-03-16
- Publication Date
- 2026-10-20
- Estimated Expiration
- 2046-03-16
AI Technical Summary
用户在表达查询意图时,往往不得不在“易于表达”和“查询能力”之间做出取舍,或频繁在不同工具间切换,效率低下
本发明通过融合描述逻辑推理与图查询能力,用户仅需使用自然语言即可表达复杂查询意图,无需掌握专业查询语言,大幅降低知识图谱使用门槛;系统能够智能识别查询中逻辑推理与关系检索部分,并分别调用最优引擎并行执行,充分发挥两类查询语言的互补优势,显著提升复杂查询的响应效率与结果准确性;同时,引入多源信息融合机制有效处理结果冲突,增强查询结果的可解释性与一致性;此外,系统具备自学习优化能力,能够根据用户行为持续改进分解策略与翻译模型,具有良好的扩展性与适应性,可广泛应用于各类基于知识图谱的智能查询场景。
Smart Images

Figure CN122220586B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of natural language processing technology, and in particular relates to a hybrid query language translation method and system based on the fusion of descriptive logic and graph query. Background Technology
[0002] With the rapid development of knowledge graph technology, its applications in intelligent search, question answering systems, and decision support are becoming increasingly widespread, and users' query needs for knowledge bases are becoming more complex. Currently, the mainstream query methods are mainly divided into two categories: one is query languages based on symbolic logic, such as Description Logic Query (DL Query) and SPARQL queries based on OWL ontology. These languages possess powerful logical reasoning capabilities, capable of deriving implicit information from explicit knowledge, but their syntax is complex, the learning curve is steep, and they are difficult for ordinary users to use directly. The other category is query languages based on graph traversal, such as Cypher and Gremlin in attribute graph databases. These languages are intuitive and easy to understand, suitable for expressing relational queries and path retrieval, but they lack native support for logical reasoning and struggle to handle complex queries requiring multiple logical derivations. Both types of query languages have their advantages, but most existing systems only support one, failing to balance ease of expression and query capabilities, thus limiting the effectiveness of knowledge graphs in complex scenarios.
[0003] Currently, existing natural language to query language translation methods mostly focus on a single query language, lacking effective support for mixed query intents. When users submit complex queries such as "all non-cooperative targets that have approached the target satellite at close range without prior notification," which involve both relational matching and logical reasoning, the system struggles to automatically identify the characteristics of different parts of the query and assign them to the appropriate query engine for execution. When expressing their query intent, users often have to make trade-offs between "ease of expression" and "query capability," or frequently switch between different tools, resulting in inefficiency. Furthermore, existing technologies lack a unified query expression and result fusion mechanism, failing to intelligently integrate logical reasoning with graph traversal results, leading to incomplete or conflicting query results that fail to meet the high requirements of accuracy, comprehensiveness, and interpretability in practical applications. Summary of the Invention
[0004] To address the aforementioned technical problems, this invention proposes a hybrid query language translation method and system based on the fusion of descriptive logic and graph query, thereby resolving the issues present in the prior art.
[0005] To achieve the above objectives, this invention provides a hybrid query language translation system based on the fusion of descriptive logic and graph queries, comprising: The Natural Language Understanding module is used to perform semantic parsing on the input natural language query and output a structured semantic representation. A query intent classifier is used to classify the intent of the structured semantic representation and identify subtasks that require logical reasoning and subtasks that require graph traversal. The query decomposer is used to split the original query into logical reasoning subqueries and graph traversal subqueries based on the classification results of the query intent classifier, and to establish the dependency relationships and result fusion rules between the subqueries. A hybrid query translator is used to convert the logical reasoning subquery into a descriptive logical query statement and the graph traversal subquery into a graph query statement; A distributed query execution engine is used to execute the description logic query statement and the graph query statement in parallel to obtain intermediate results; The result fusion module is used to merge and handle conflicts of the intermediate results according to the result fusion rules to generate the final query results.
[0006] Optionally, the natural language understanding module includes: The entity recognition unit is used to extract the concepts and instances mentioned in the query and map them to the knowledge graph ontology or graph node labels; The relation extraction unit is used to identify semantic relationships between entities and convert them into edge types in the role or attribute graph in the description logic; The attribute constraint extraction unit is used to extract numeric and string attribute conditions from the query; The logical condition parsing unit is used to identify logical structures in natural language and generate logical expression trees.
[0007] Optionally, the query intent classifier includes: The rule prediction unit is used to match the query text based on a predefined set of keywords, and to initially mark the logical reasoning part and the graph traversal part; The model classification unit is used to transform the structured semantic representation into feature vectors and input them into the classification model, and output the probability that each subtask belongs to logical reasoning or graph traversal. The comprehensive decision unit is used to combine the rule matching results and model classification probabilities to determine the final type label and confidence level of each subtask.
[0008] Optionally, the query decomposer includes: The logical subquery generation unit is used to construct a descriptive logical abstract syntax tree for the parts marked as logical reasoning. The graph traversal subquery generation unit is used to construct an attribute graph query abstract syntax tree for the parts marked as graph traversals. The dependency and fusion rule definition unit is used to specify the execution order of each subquery and the method of merging intermediate results.
[0009] Optionally, the hybrid query translator includes: The Description Logic Query Generation submodule is used to convert the description logic abstract syntax tree of logical reasoning subqueries into standard DL Query or SPARQL query statements; The graph query generation submodule is used to convert the attribute graph query abstract syntax tree of the graph traversal subquery into Cypher or Gremlin query statements; The query optimization submodule is used to construct a subquery dependency graph and estimate the execution cost of each subquery, generating an optimized execution plan that includes execution order and parallelism settings.
[0010] Optionally, the distributed query execution engine includes: The inference engine connection unit is used to submit the description logic query statement to the OWL inference engine for execution and return a set of individuals or concepts that meet the conditions. The graph database connection unit is used to submit graph query statements to the graph database for execution and return nodes, edges, or paths. The parallel scheduling unit is used to execute queries from both engines in parallel and collect results using a multi-threaded or distributed computing framework, based on an optimized execution plan.
[0011] Optionally, the result fusion module includes: The rule application unit is used to combine intermediate results according to predefined fusion rules; The conflict resolution unit is used to calculate the credibility of each subquery result, apply DS evidence theory to fuse multi-source evidence and calculate the overall confidence level, and generate feedback information to request clarification from the user when the confidence level is lower than the threshold.
[0012] Optionally, the system further includes a self-learning optimization module, which includes: The user behavior log collection submodule is used to record the complete context of each query and subsequent user actions. The feedback annotation submodule is used to convert user behavior into reward signals in reinforcement learning; The strategy update submodule is used to optimize the classification threshold, decomposition rule weights in the query decomposer, and query generation template parameters in the hybrid query translator using reinforcement learning algorithms.
[0013] This invention also provides a hybrid query language translation method based on the fusion of descriptive logic and graph queries, for implementing the aforementioned system. The method includes the following steps: Perform semantic parsing on the input natural language query and output a structured semantic representation; The structured semantic representation is classified by intent to identify subtasks that require logical reasoning and subtasks that require graph traversal. Based on the classification results, the original query is split into logical reasoning subqueries and graph traversal subqueries, and the dependency relationships between subqueries and result fusion rules are established. The logical reasoning subquery is converted into a descriptive logical query statement, and the graph traversal subquery is converted into a graph query statement; The description logic query statement and the graph query statement are executed in parallel to obtain intermediate results; The intermediate results are merged and conflict resolution is performed according to the result fusion rules to generate the final query result.
[0014] Compared with the prior art, the present invention has the following advantages and technical effects: This invention integrates descriptive logical reasoning with graph query capabilities, allowing users to express complex query intentions using only natural language without needing to master specialized query languages, significantly lowering the barrier to entry for knowledge graph usage. The system intelligently identifies the logical reasoning and relational retrieval components in a query and executes them in parallel using the optimal engine, fully leveraging the complementary advantages of the two query languages to significantly improve the response efficiency and accuracy of complex queries. Simultaneously, a multi-source information fusion mechanism effectively handles result conflicts, enhancing the interpretability and consistency of query results. Furthermore, the system possesses self-learning optimization capabilities, continuously improving its decomposition strategy and translation model based on user behavior, exhibiting excellent scalability and adaptability, and can be widely applied to various knowledge graph-based intelligent query scenarios. Attached Figure Description
[0015] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is an overall architecture diagram of the hybrid query language translation system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the query decomposition and translation process in an embodiment of the present invention. Figure 3 This is a schematic diagram of conflict handling in the result fusion module of this invention. Figure 4 This is a schematic diagram of the structure of the self-learning optimization module in an embodiment of the present invention; Figure 5 This is an example diagram illustrating the application of the present invention in a space situation query scenario. Detailed Implementation
[0016] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.
[0017] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.
[0018] Example 1 like Figure 1 As shown, this embodiment provides a hybrid query language translation system based on the fusion of descriptive logic and graph queries. The system aims to automatically translate natural language queries into hybrid queries that simultaneously utilize descriptive logic reasoning and graph database traversal capabilities, and efficiently execute and return comprehensive results. The system consists of seven core modules, which work collaboratively to achieve the entire process from natural language understanding to result feedback optimization. The overall system flow is as follows: The user inputs a natural language query; the natural language understanding module performs semantic parsing and extracts structured information; the query intent classifier determines which parts of the query require logical reasoning and which require graph traversal; the query decomposer breaks the query into multiple subqueries based on the classification results and establishes dependency and fusion rules between subqueries; the hybrid query translator converts the intermediate representation of the subqueries into a specific query language (DL Query / SPARQL, Cypher / Gremlin) and optimizes it; the distributed query execution engine calls the OWL inference engine and graph database in parallel to execute the query and obtain intermediate results; the result fusion module merges sub-results according to predefined rules, handles conflicts, and generates the final result; the self-learning optimization module records user behavior and feedback, and continuously optimizes the decomposition strategy and translation model through reinforcement learning.
[0019] The specific implementation of each module is as follows: The Natural Language Understanding module receives natural language queries input by the user and performs semantic parsing on the queries using a large language model, identifying core entities, relationships, attribute constraints, and logical conditions within the query. The input is the user's natural language query (such as a Chinese or English sentence); the output is a structured semantic representation, including a list of core entities, a list of relationships, attribute constraints (key-value pairs), and logical conditions (such as implication, quantifiers, and Boolean operators).
[0020] The Natural Language Understanding module includes: an entity recognition unit, used to extract concepts and instances mentioned in the query and map them to the knowledge graph ontology or graph node labels; a relation extraction unit, used to identify semantic relationships between entities and convert them into roles in the description logic or edge types in the attribute graph; an attribute constraint extraction unit, used to extract numerical and string attribute conditions in the query; and a logical condition parsing unit, used to identify the logical structure in the natural language and generate a logical expression tree.
[0021] The specific implementation process includes: 1) Semantic parsing using pre-trained large language models (such as GPT-4, LLaMA). Through prompting engineering or fine-tuning, the model is able to identify entity mentions, relational phrases, attribute descriptions, and logical connectives in the query. 2) Entity recognition: Extracting the concepts and instances involved in the query and mapping them to ontology or graph node labels in the knowledge graph. 3) Relation extraction: Identifying semantic relationships between entities, such as "belongs to," "located in," "cause," etc., and converting them into edge types in the attribute graph or roles in the description logic. 4) Attribute constraints: Extracting attribute conditions such as numerical values and strings, such as "age greater than 30" and "color is red." 5) Logical condition parsing: Identifying logical structures in natural language, such as "all A are B" (implication), "there exists a C that satisfies D" (existential quantifier), "if P then Q" (rule), etc., and generating a logical expression tree.
[0022] The query intent classifier categorizes the parsed query intent, breaking it down into parts requiring logical reasoning and parts requiring graph traversal. It identifies the logical reasoning subtask by recognizing parts of the query that require logical reasoning, such as logical implication, classification reasoning, consistency checks, and rule triggering. It also identifies the graph traversal subtask by recognizing parts of the query that require graph traversal, such as path queries, neighborhood retrieval, pattern matching, and similarity calculation. The input is the structured semantic representation (or the vector representation of the original query) output by the natural language understanding module. The output is a type label for each subtask (probability of logical reasoning requirement, probability of graph traversal requirement) and the corresponding confidence score.
[0023] The query intent classifier includes: a rule prediction unit, used to match the query text based on a predefined set of keywords, and initially label the logical reasoning part and the graph traversal part; a model classification unit, used to convert the structured semantic representation into a feature vector and input it into the classification model, and output the probability that each subtask belongs to logical reasoning or graph traversal; and a comprehensive judgment unit, used to combine the rule matching results and the model classification probability to determine the final type label and confidence level of each subtask.
[0024] The specific implementation process includes: 1) Rule prediction: Matching the query text based on a predefined set of keywords (such as "all", "exist", "if...then", "implies", "must", "may", etc.) to initially mark parts that may involve logical reasoning. Simultaneously, marking path descriptions (such as "connected through...", "shortest path", "neighbors") and pattern matching phrases (such as "similar to", "related to") to indicate graph traversal requirements. 2) Model classification: Converting the semantically parsed query structure (such as an entity-relationship graph) into feature vectors (such as using graph neural networks or Transformer encoding), inputting them into a lightweight classification model (such as a multilayer perceptron or XGBoost) for binary or multi-label classification, and outputting the probability that each part belongs to logical reasoning or graph traversal. This model can be trained on historical query data. 3) Comprehensive judgment: Combining the rule matching results and model probabilities, the final classification label is determined using a threshold or weighted method. For example, if the logical keywords match and the model probability is higher than 0.7, it is judged as a logical reasoning subtask; if both are low, it may be a hybrid type, requiring further decomposition.
[0025] The query decomposer, based on the results of the query intent classifier, breaks down the original query into multiple subqueries and establishes dependencies and result fusion rules between the subqueries, where: Input: A structured semantic representation with category labels.
[0026] Output: An intermediate representation of a set of subqueries, including: 1) a descriptive logical representation of logical reasoning subqueries (in the form of an abstract syntax tree); 2) an attribute graph query representation of graph traversal subqueries (in the form of an abstract syntax tree); 3) dependencies between subqueries (such as sequential execution, parallel execution, nesting) and result fusion rules (such as intersection, union, difference, conditional filtering).
[0027] The query decomposer includes: a logical subquery generation unit, used to construct a descriptive logical abstract syntax tree for the parts marked as logical reasoning; a graph traversal subquery generation unit, used to construct an attribute graph query abstract syntax tree for the parts marked as graph traversal; and a dependency and fusion rule definition unit, used to define the execution order of each subquery and the merging method of intermediate results.
[0028] The specific implementation process includes: 1) Logical subquery generation: For the parts marked as logical reasoning, an abstract syntax tree describing the logic is constructed. Tree nodes include concepts (classes), roles (relationships), individuals (instances), and constructors (intersection, union, complement, existential quantifiers, value constraints, etc.). All logical constraints in the original query are retained, such as "All engineers are employees" being transformed into Engineer ⊑ Employee, and "There exists a project led by John" being transformed into ∃leads.{John} ⊑ Project.
[0029] 2) Graph Traversal Subquery Generation: For the parts marked as graph traversal, construct an abstract syntax tree (AST) using Cypher or Gremlin. Tree nodes include node patterns, edge patterns, path constraints, attribute filtering, aggregate functions, etc. For example, "Find all companies that have a cooperative relationship with company A" is transformed into (a:Company {name:'A'})-[:cooperation]->(b:Company).
[0030] 3) Mixed Part Processing: For parts involving both logic and graph traversal, introduce intermediate variables to achieve step-by-step processing. For example, the query "all colleagues of engineers who have participated in AI projects and are older than 30" can be decomposed into: a. Graph Traversal: Find all engineers who participated in AI projects → obtain candidate set C1. b. Logical Reasoning: For each individual in C1, reason about their colleagues (possibly defined by rules) and filter for those older than 30 → obtain result set. In this case, the dependency relationship is: step b depends on the result of step a, and the fusion rule is that step b directly filters. 4) Dependency and Fusion Rule Definition: Clarify the execution order (serial / parallel) of each subquery and the result merging method. Common fusion rules include: Intersection: Entities that satisfy both logical reasoning and graph traversal conditions. Union: Entities that satisfy either condition. Difference: Entities that satisfy logical reasoning but not graph traversal (or vice versa). Join: Using the result of logical reasoning as the input parameter of the graph query (such as the IN clause). Conditional Filtering: Using the result of graph traversal as the assertion condition of logical reasoning.
[0031] The hybrid query translator includes a descriptive logic query generation submodule, which converts the descriptive logic representation of logical reasoning subtasks into standard DL Query or SPARQL query statements; a graph query generation submodule, which converts the attribute graph query representation of graph traversal subtasks into Cypher / Gremlin query statements; and a query optimization submodule, which optimizes the syntax and execution order of the generated query statements. The input consists of the subquery intermediate representation (AST) and dependencies output by the query decomposer. The output consists of the specific executable query statements, including: 1) descriptive logic query statements (DL Query or SPARQL); 2) graph query statements (Cypher or Gremlin); and 3) optimized execution plans (e.g., execution order, parallelism).
[0032] The specific implementation process includes: 1) Description of logical query generation submodule: Convert the AST of logical reasoning subqueries into standard DL query format, for example: a. If using the OWL inference engine, Manchester Syntax or DL Query strings can be generated, such as Person and (hasAge some integer[>30]). b. If using the RDF triple library, SPARQL query is generated, which contains the OWL constructs required for inference (such as FILTER EXISTS, OPTIONAL combined with inference rules). 2) Graph query generation submodule: Convert the AST of graph traversal subqueries into the query language of the target graph database, such as: a. Neo4j's Cypher statement, such as MATCH (p:Person)-[:worksAt]->(c:Company) WHERE p.age>30 RETURN p. b. JanusGraph's Gremlin statement, such as gV().hasLabel('Person').has('age',gt(30)).out('worksAt'). 3) Query Optimization Submodule: This submodule performs syntax optimization (e.g., simplifying redundant conditions, merging paths) and execution order optimization (adjusting the subquery execution order based on dependencies, leveraging parallelism) on the generated query statements. The core optimization goal is to minimize overall query response time and resource consumption by optimizing the subquery execution order after converting the abstract syntax tree (AST) of the subqueries into concrete query statements. For example, subqueries that can be executed in parallel are marked for parallel execution, subqueries requiring data dependencies are arranged sequentially, and intermediate result caching may be introduced. The specific optimization logic is as follows: a. Constructing a Subquery Dependency Graph (DAG): Using subqueries as nodes and dependencies as directed edges, a directed acyclic graph (DAG) is formed. If there are no dependencies, the nodes are independent of each other. b. Estimating Subquery Costs: For each subquery, its execution cost is estimated (e.g., estimated time consumption, memory usage, number of rows returned). Cost estimation is based on static characteristics: query complexity (e.g., inference depth, path length), the amount of data involved (based on statistical information), and index usage. Dynamic History: Historical execution times of similar queries are obtained from the self-learning optimization module. Rule-based heuristics: For example, subqueries with constraints in graph traversal are generally faster than those without; reasoning queries involving a large number of individuals may be slower. c. Generating an initial execution plan includes parallelization: marking dependent subqueries in the DAG as parallelizable and distributing them across different threads or distributed nodes. Topological sorting: performing a topological sort on dependent subqueries to determine a basic sequential order. Cost-driven rearrangement: adjusting the topological sort based on cost factors.For example, if two subqueries run in parallel but resources are limited (e.g., only one inference engine instance), they should be serialized; if a subquery is extremely costly, consider breaking it down or delaying its execution. d. Applying heuristics includes: small-to-large: prioritize executing subqueries with smaller expected result sets and lower costs to release resources early, while their output may provide filtering conditions for subsequent large queries, reducing subsequent processing load. Filtering before inference: if a graph traversal subquery can quickly narrow down the candidate set, execute it first, then use the result as input for logical inference, significantly reducing the inference burden. Materialization tradeoffs: for intermediate results that are depended on by multiple subsequent queries, consider materializing (temporarily storing) them to avoid redundant computation; for pipeline data used only once, directly pass the streaming results. Engine affinity: if a certain engine is currently under low load, prioritize assigning subqueries to it. e. Dynamic tuning and runtime optimization include monitoring the actual execution time of each subquery during execution. If a subquery's execution time significantly exceeds expectations, the optimizer can dynamically adjust the order of subsequent unexecuted subqueries (e.g., changing parallel subqueries to serial subqueries to release resources, or executing other low-cost queries earlier). This dynamic tuning capability relies on the feedback mechanism provided by the distributed execution engine. f. The final execution plan output includes submitting the optimized execution order (including parallelism settings) along with the specific query statements to the distributed query execution engine.
[0033] A distributed query execution engine connects to the OWL inference engine and the graph database, executing the generated descriptive logic queries and graph queries in parallel and obtaining intermediate results. Inputs include: optimized hybrid query statements (DL queries and graph queries) and execution plans. Outputs include: intermediate result sets for each subquery (possibly in the form of tables or image segments).
[0034] The distributed query execution engine includes: an inference engine connection unit, which submits logical query statements to the OWL inference engine for execution and returns a set of individuals or concepts that meet the conditions; a graph database connection unit, which submits graph query statements to the graph database for execution and returns nodes, edges, or paths; and a parallel scheduling unit, which executes the queries of the two engines in parallel using multi-threading or a distributed computing framework according to an optimized execution plan and collects the results.
[0035] The specific implementation process includes: 1) Connecting to the OWL inference engine: Submitting the descriptive logic query to the inference engine (such as Pellet, HermiT, RDF4J), the engine performs inference based on the ontology and rules, and returns a set of individuals or concepts that meet the conditions. 2) Connecting to the graph database: Submitting the graph query to the graph database (such as Neo4j, Amazon Neptune), performing graph traversal, and returning nodes, edges, or paths. 3) Parallel scheduling: According to the execution plan, using multi-threading or distributed computing frameworks (such as Spark) to execute the queries of the two engines in parallel, monitoring the execution status, and handling timeouts and errors. 4) Result collection: Unifying the results returned by each engine into an internal data structure (such as a JSON object or DataFrame), temporarily storing them in memory or temporary storage for use by the result fusion module.
[0036] The result fusion module receives the execution results of multiple subqueries, merges the results according to predefined fusion rules from the query decomposer, handles potential conflicts, and finally generates a comprehensive query result. Input: Intermediate result sets of each subquery, and fusion rules defined by the query decomposer. Output: The final comprehensive query result.
[0037] The results fusion module includes: a rule application unit, used to combine intermediate results according to predefined fusion rules; and a conflict handling unit, used to calculate the credibility of each subquery result, apply DS evidence theory to fuse multi-source evidence and calculate the comprehensive confidence level, and generate feedback information to request clarification from the user when the confidence level is lower than the threshold.
[0038] The specific implementation process includes: 1) Rule application: Combining intermediate results according to fusion rules (intersection, union, etc.). For example, performing set operations on two sets; or using graph traversal results as filtering conditions for logical reasoning results. 2) Conflict handling: When results from different sources contradict each other regarding the same entity or attribute (e.g., logical reasoning posits someone as an engineer, but the graph query shows they are not), a confidence propagation mechanism is used. 3) Calculating the confidence level for each subquery result, considering factors such as: data source quality (e.g., ontology completeness, graph data freshness), query complexity (e.g., reasoning depth, path length), and historical accuracy (obtained from the self-learning module). 4) Applying Dempster-Shafer (DS) evidence theory to fuse multi-source evidence, calculating the overall confidence level of each conclusion, selecting the conclusion with the highest confidence level, or returning multiple possible results and labeling their confidence levels. 5) If conflicts cannot be resolved automatically (e.g., similar confidence levels and no additional information), the conflict information is fed back to the user, requesting clarification or selection. 6) Result formatting: Organize the merged results in a user-friendly way, such as natural language sentences, tables, or graph structures.
[0039] The self-learning optimization module records user query history and feedback on query results, continuously optimizing the query decomposition strategy and translation accuracy through reinforcement learning. Inputs: User query history, user feedback on results (clicks, modifications, ratings, etc.), execution logs. Outputs: Optimized query decomposition strategy parameters, translation model parameters.
[0040] The self-learning optimization module includes: a user behavior log collection submodule, used to record the complete context of each query and subsequent user actions; a feedback annotation submodule, used to convert user behavior into reward signals in reinforcement learning; and a policy update submodule, used to optimize the classification threshold, decomposition rule weights in the query decomposer, and query generation template parameters in the hybrid query translator using reinforcement learning algorithms.
[0041] The specific implementation process includes: 1) User behavior log collection submodule: Recording the complete context of each query, including the original query, intermediate outputs of each module, the final result, and subsequent user actions (such as clicking details, modifying the query, and rating). 2) Feedback annotation submodule: Transforming user behavior into reward signals in reinforcement learning. For example, if the user directly adopts the result (without modification), a positive reward is given; if the user modifies the query or abandons it, a negative reward is given; if the user clicks on the result details, it can be considered as partial satisfaction. 3) Policy update submodule: Using reinforcement learning algorithms (such as policy gradient, Q-learning) to optimize the classification threshold, decomposition rule weights in the query decomposer, and query generation template parameters in the hybrid query translator. The goal is to maximize long-term cumulative rewards. Specifically, the decomposition policy can be modeled as a decision network, and user feedback can be used as a loss function for updating. At the same time, the large language model of the natural language understanding module can also be fine-tuned through user feedback (such as using human feedback reinforcement learning RLHF).
[0042] Example 2 The overall architecture of the hybrid query language translation system is as follows: Figure 1 As shown, the system includes: Natural Language Understanding Module: Integrates large language models (such as ChatGLM-6B) to perform semantic parsing on natural language queries input by users and output structured representations (entities, relations, attribute constraints, logical conditions).
[0043] Query Intent Classifier: Based on rules and the LightGBM classification model, query intent is classified into logical reasoning, graph traversal, and hybrid types, and the weights of each subtask are output.
[0044] Query decomposer: breaks down mixed queries into multiple subqueries and generates a subquery dependency graph.
[0045] Hybrid Query Translator: Includes a DL query generator (converting logical reasoning subtasks into SPARQL), a Cypher query generator (converting graph traversal subtasks into Cypher), and a query optimizer.
[0046] Distributed query execution engine: It uses a thread pool to call the Pellet inference engine and Neo4j graph database in parallel to obtain subquery results.
[0047] Results fusion module: Uses DS evidence theory to fuse multi-source results and generate the final query result.
[0048] Self-learning optimization module: Records user interaction logs and optimizes query decomposition strategies through reinforcement learning.
[0049] The workflow of query decomposition and translation is as follows: Figure 2 As shown, when receiving the natural language query "Find all non-cooperative targets that are less than 10 kilometers from the space station and have not reported communication in the past 24 hours": The natural language understanding module parses out entities (space station, non-cooperative target), relationships (distance less than 10 kilometers), attribute constraints (within the past 24 hours), and logical conditions (no communication reporting).
[0050] Query intent classifier determination: "Distance less than 10 kilometers" belongs to the graph traversal subtask (requires calculation of spatial distance and neighborhood retrieval); "Failure to report communication" is a logical reasoning subtask (it is necessary to determine compliance based on communication records and reporting rules).
[0051] The query decomposer generates two subqueries: Subquery A (graph traversal): MATCH (t:Target)-[:PROXIMITY {distance<10}]->(s:Station {name:'Space Station'}) RETURN t, retrieves the candidate target set; Subquery B (logical reasoning): SELECT ?t WHERE {?t :hasCommunicationLog ?log. ?log:time>?t-24h. ?log :reportStatus false}, filters out unreported targets from the candidate target set.
[0052] The hybrid query translator converts subquery A into Cypher and subquery B into SPARQL.
[0053] The distributed query execution engine executes in parallel: first, Cypher is executed in Neo4j to obtain the candidate set, and then the candidate set is passed as input to Pellet to perform SPARQL filtering.
[0054] The result fusion module combines the results of the two queries and outputs the final list.
[0055] Conflict handling in the result fusion module is as follows: Figure 3 As shown, a conflict arises when a graph query returns "within the distance constraint range" for a target, while logical reasoning returns "the target has been reported." Result fusion module: The reliability of the computation graph query results is 0.95 (based on historical statistics of sensor accuracy). The reliability of the logical reasoning result is calculated (0.98, based on the integrity of the communication records). Using the DS evidence theory synthesis rules, the overall confidence level that the target belongs to "unreported close-range target" is calculated; When the overall confidence level is below the threshold (e.g., 0.8), conflict information is fed back to the user requesting clarification: "The target distance is correct, but the communication status is questionable. Please confirm the integrity of the communication records."
[0056] The implementation of the self-learning optimization module is as follows: Figure 4 As shown, the self-learning optimization module includes: User behavior log collection: Records each user query, clicked search results, modified queries, etc.
[0057] Feedback labeling: Users clicking "satisfied with the result" are given positive feedback, while abandoning the query or re-entering the information is given negative feedback.
[0058] Policy Network: The policy gradient method is used to optimize the query decomposition strategy, such as adjusting the "logical keyword weight" and "classification threshold".
[0059] Regular updates: The query intent classifier and optimizer parameters are retrained weekly based on newly added logs to continuously improve translation accuracy.
[0060] Applications in aerospace situation query scenarios, such as Figure 5 As shown, this system is deployed in a certain aerospace command center: The operator inputs in natural language: "What non-cooperative targets have approached our satellite in the last 24 hours?" The system automatically translated it into a mixed query: Image query: Identify all non-cooperative targets and calculate their historical trajectory distances from our satellites; Logical reasoning: Filter the graph query results based on the proximity rule base (e.g., "proximity" is defined as "relative distance < 5km and relative speed < 0.1km / s and duration > 10 minutes").
[0061] The returned results include: a list of targets, the time of the approach event, a trajectory map, and the reasoning basis ("determined to be approaching according to rule R12").
[0062] When the operator clicks "Confidence Details", the system displays the inference path: rule triggering records, graph query trajectory matching process, and confidence calculation basis.
[0063] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A hybrid query language translation system based on the fusion of descriptive logic and graph queries, characterized in that, include: The Natural Language Understanding module is used to perform semantic parsing on the input natural language query and output a structured semantic representation. A query intent classifier is used to classify the intent of the structured semantic representation and identify subtasks that require logical reasoning and subtasks that require graph traversal. A query decomposer is used to split the original query into logical reasoning subqueries and graph traversal subqueries based on the classification results of the query intent classifier, and to establish dependencies and result fusion rules between the subqueries; the dependencies are used to determine the execution order of each subquery, which includes sequential execution, parallel execution, or nested execution; the result fusion rules include intersection, union, difference, join, or conditional filtering. The query decomposer includes: a logical subquery generation unit, used to construct a descriptive logical abstract syntax tree for the parts marked as logical reasoning; a graph traversal subquery generation unit, used to construct an attribute graph query abstract syntax tree for the parts marked as graph traversal; and a dependency and fusion rule definition unit, used to define the execution order of each subquery and the merging method of intermediate results. A hybrid query translator is used to convert the logical reasoning subquery into a descriptive logical query statement and the graph traversal subquery into a graph query statement; The hybrid query translator includes: a description logic query generation submodule, used to convert the description logic abstract syntax tree of logical reasoning subqueries into standard DL Query or SPARQL query statements; a graph query generation submodule, used to convert the attribute graph query abstract syntax tree of graph traversal subqueries into Cypher or Gremlin query statements; and a query optimization submodule, used to construct a subquery dependency graph, determine the execution order of each subquery based on the data dependencies between subqueries, mark subqueries without dependencies as parallel execution, arrange subqueries with dependencies as serial execution, and generate an optimized execution plan containing execution order and parallelism settings. A distributed query execution engine is used to execute the description logic query statement and the graph query statement according to the execution order of each sub-query determined in the optimized execution plan, and obtain intermediate results; The distributed query execution engine includes: an inference engine connection unit, used to submit a logical query statement to the OWL inference engine for execution and return a set of individuals or concepts that meet the conditions; a graph database connection unit, used to submit a graph query statement to the graph database for execution and return nodes, edges, or paths; and a parallel scheduling unit, used to execute the queries of the two engines in parallel using a multi-threaded or distributed computing framework according to an optimized execution plan and collect the results. The result fusion module is used to merge and handle conflicts of the intermediate results according to the result fusion rules to generate the final query results.
2. The hybrid query language translation system based on the fusion of description logic and graph query as described in claim 1, characterized in that, The natural language understanding module includes: The entity recognition unit is used to extract the concepts and instances mentioned in the query and map them to the knowledge graph ontology or graph node labels; The relation extraction unit is used to identify semantic relationships between entities and convert them into edge types in the role or attribute graph in the description logic; The attribute constraint extraction unit is used to extract numeric and string attribute conditions from the query; The logical condition parsing unit is used to identify logical structures in natural language and generate logical expression trees.
3. The hybrid query language translation system based on the fusion of descriptive logic and graph query as described in claim 1, characterized in that, The query intent classifier includes: The rule prediction unit is used to match the query text based on a predefined set of keywords, and to initially mark the logical reasoning part and the graph traversal part; The model classification unit is used to transform the structured semantic representation into feature vectors and input them into the classification model, and output the probability that each subtask belongs to logical reasoning or graph traversal. The comprehensive decision unit is used to combine the rule matching results and model classification probabilities to determine the final type label and confidence level of each subtask.
4. The hybrid query language translation system based on the fusion of description logic and graph query as described in claim 1, characterized in that, The result fusion module includes: The rule application unit is used to combine intermediate results according to predefined fusion rules; The conflict resolution unit is used to calculate the credibility of each subquery result, apply DS evidence theory to fuse multi-source evidence and calculate the overall confidence level, and generate feedback information to request clarification from the user when the confidence level is lower than the threshold.
5. The hybrid query language translation system based on the fusion of description logic and graph query as described in claim 4, characterized in that, The system further includes a self-learning optimization module, which includes: The user behavior log collection submodule is used to record the complete context of each query and subsequent user actions. The feedback annotation submodule is used to convert user behavior into reward signals in reinforcement learning; The strategy update submodule is used to optimize the classification threshold, decomposition rule weights in the query decomposer, and query generation template parameters in the hybrid query translator using reinforcement learning algorithms.
6. A hybrid query language translation method based on the fusion of descriptive logic and graph queries, characterized in that, For implementing the system as described in any one of claims 1-5, the method comprises the following steps: Perform semantic parsing on the input natural language query and output a structured semantic representation; The structured semantic representation is classified by intent to identify subtasks that require logical reasoning and subtasks that require graph traversal. Based on the classification results, the original query is split into logical reasoning subqueries and graph traversal subqueries, and the dependency relationships between subqueries and result fusion rules are established. The logical reasoning subquery is converted into a descriptive logical query statement, and the graph traversal subquery is converted into a graph query statement; Based on the execution order determined by the dependencies, the description logic query statement and the graph query statement are executed to obtain intermediate results; The intermediate results are merged and conflict resolution is performed according to the result fusion rules to generate the final query result.
Citation Information
Patent Citations
Graph logic execution plan generation method of graph query statement and data processing method and device
CN117785884A
Database query language transformation method, transformation apparatus and database query system
US20070299836A1