Query language generation method, apparatus and device

Abstract

The application discloses a query language generation method, device and equipment. The method comprises the following steps: acquiring a graph database query requirement expressed in a natural language form; acquiring a code name of a target graph element type matched with a semantic name and a query keyword according to the semantic name and the code name of the graph element type; and generating a graph query statement corresponding to the query requirement through a large language model according to the code name of the target graph element type and the query requirement. In this way, the large language model can convert the natural language into a graph query language according to the graph element type (Schema subset) matched with the query requirement, the large language model can avoid generating the graph query language according to a complete graph Schema, the solution space of the large language model can be greatly reduced, the attention of the large language model can be prevented from being distracted due to the overload of the Schema information, and therefore the accuracy of the conversion from the natural language to the graph query language can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of natural language processing technology, specifically to query language generation methods and apparatus, as well as electronic devices. Background Technology

[0002] Large Language Model (LLM) technology continues to iterate and evolve, with increasingly diverse application scenarios. Natural Language to Graph Query Language (NL2GQL) is one such typical application.

[0003] Currently, a typical approach to converting natural language into graph query language involves sending the complete encoded graph schema of the graph database and the user's natural language question (user query) to the LLM. The LLM, in conjunction with the encoded schema understanding, maps the semantic intent into nodes (tags), relations (edges), and attribute expressions of the graph structure, and automatically generates graph database query statements.

[0004] However, in implementing this application, the applicant discovered that existing solutions have at least the following problems: Schema information overload can lead to LLM attention distraction, resulting in schema illusion (LLM fabricating non-existent node names) and attribute name errors (using semantic attribute names instead of actual encoded names). Schema illusions include using "phone" instead of "eba_object_data_102001," and attribute name errors include "phone_number." Therefore, how to improve the accuracy of graph query statement generation in schema-encoded scenarios is an urgent problem that needs to be researched and addressed. Summary of the Invention

[0005] This application provides a query language generation method to address the problem of low accuracy in generating graph query statements under encoded schema scenarios in existing technologies. This application also provides a query language generation apparatus and an electronic device.

[0006] This application provides a query language generation method, including: Obtain graph database query requirements expressed in natural language; Based on the semantic name and encoded name of the graph element type, obtain the encoded name of the target graph element type whose semantic name matches the query keywords; Based on the encoded name of the target graph element type and the query requirements, a graph query statement corresponding to the query requirements is generated using a large language model.

[0007] Optionally, obtaining the encoded name of the target graph element type whose semantic name matches the query keyword based on the semantic name and encoded name of the graph element type includes: Based on the semantic name and encoded name of the graph element type, obtain the encoded name of the first target graph element type whose semantic name matches the text of the query keyword.

[0008] Optionally, the step of obtaining the encoded name of the target graph element type whose semantic name matches the query keyword based on the semantic name and encoded name of the graph element type further includes: If no encoding name exists for the first target graph element type, then based on the semantic name and encoding name of the graph element type, obtain the encoding name of the second target graph element type whose semantic name is similar to the character-level semantics of the query keyword.

[0009] Optionally, the step of obtaining the encoded name of the target graph element type whose semantic name matches the query keyword based on the semantic name and encoded name of the graph element type further includes: If no encoding name for the second target graph element type exists, then based on the graph pattern, obtain the semantic names of multiple graph element types; using the large language model, based on the semantic names of the multiple graph element types, obtain the encoding name of the third target graph element type whose semantic name is semantically similar to the query keyword from the multiple graph element types.

[0010] Optionally, the step of obtaining the encoded name of the target graph element type whose semantic name matches the query keyword based on the semantic name and encoded name of the graph element type further includes: If the query keyword has multiple meanings, then according to the query requirements, the encoding name of the target graph element type that matches the query keyword is selected from the multiple candidate graph element type encoding names with different meanings corresponding to the query keyword.

[0011] Optionally, the step of selecting the encoding name of the target graph element type that matches the query keyword from multiple candidate graph element type encoding names with different meanings corresponding to the query keyword, based on the query requirement, includes: Obtain a list of positive enhancing keywords and / or a list of negative excluding keywords for candidate graph element types; If the query request includes keywords from the positive reinforcement keyword list, then increase the confidence of the candidate graph element type; If the query request includes keywords from the negative boosting keyword list, then reduce the confidence of the candidate graph element type; Based on the adjusted confidence of the candidate graph element types, select the code name of the target graph element type that matches the query keyword from multiple candidate graph element type code names with different meanings.

[0012] Optionally, the step of selecting the encoding name of the target graph element type that matches the query keyword from multiple candidate graph element type encoding names with different meanings corresponding to the query keyword, based on the query requirement, includes: Obtain the disambiguation rules corresponding to the query keywords. The disambiguation rules include the preset candidate graph element types corresponding to the query keywords, the positive enhancement keyword list of the preset candidate graph element types, and the negative exclusion keyword list. Increase the confidence level of candidate image element types based on the number of keywords in the positive enhancement keyword list that includes preset candidate image element types in the query requirements; Based on the number of keywords in the negative enhancement keyword list that includes preset candidate image element types in the query requirements, the confidence of the candidate image element types is reduced. Based on the adjusted confidence of the candidate graph element types, select the encoding name of the target graph element type that matches the query keywords from multiple candidate graph element type encoding names with different meanings.

[0013] Optionally, the step of selecting the encoding name of the target graph element type that matches the query keyword from multiple candidate graph element type encoding names with different meanings corresponding to the query keyword, based on the query requirement, includes: Based on the query requirements, identify the target intent type; Based on the target intent type, obtain the confidence adjustment weights for different intent types; Adjust the weights based on the confidence levels of different intent types, and adjust the confidence levels of candidate graph element types accordingly; Based on the adjusted confidence of the candidate graph element types, select the encoding name of the target graph element type that matches the query keywords from multiple candidate graph element type encoding names with different meanings.

[0014] Optionally, the step of selecting the encoding name of the target graph element type that matches the query keyword from multiple candidate graph element type encoding names with different meanings corresponding to the query keyword, based on the query requirement, includes: Get the historical success rate of mapping query keywords to candidate graph element types; Adjust the confidence level of candidate graph element types based on historical success rates; Based on the adjusted confidence of the candidate graph element types, select the encoding name of the target graph element type that matches the query keywords from multiple candidate graph element type encoding names with different meanings.

[0015] Optionally, the step of generating a graph query statement corresponding to the query requirement using a large language model based on the encoded name of the target graph element type and the query requirement includes: Based on the coded names of the target graph element types and the query requirements, obtain the structured query elements; Using a large language model, a graph query statement corresponding to the query requirements is generated based on structured query elements.

[0016] Optionally, obtaining structured query elements based on the encoded name of the target graph element type and the query requirements includes: Based on the query requirements, the source graph element type and the target graph element type are determined from the multiple target graph element types that match multiple query keywords respectively. Using a large language model, attribute values ​​corresponding to the source attribute names used as query condition elements are extracted from the query requirements.

[0017] Optional, also includes: Obtain historical query requests similar to the stated query request; The step of generating a graph query statement corresponding to the query requirement using a large language model based on the encoded name of the target graph element type and the query requirement includes: Based on the encoded name of the target graph element type, the query requirement, and the graph query statements of similar historical query requirements, a graph query statement corresponding to the query requirement is generated through a large language model.

[0018] Optionally, obtaining historical query requests similar to the query request includes: Based on the query requirements, identify the target intent type; Based on the target intent type, as well as the review status and / or processing stage of historical query requests, obtain the historical query requests that meet the criteria. Select historical query requests that are semantically similar to the query request from the historical query requests that meet the conditions.

[0019] Optionally, selecting historical query requests that are semantically similar to the query request from the qualified historical query requests includes: Based on the historical query requirements, the graph query statements of the historical query requirements, and the target intent type of the historical query requirements, determine the semantic vector of the historical query requirements; Based on the semantic vector of the historical query requirements, select historical query requirements that are semantically similar to the query requirements from the historical query requirements that meet the conditions.

[0020] Optionally, identifying the target intent type based on the query request includes: Obtain the graph element types related to the query requirements; By using a large language model, the target intent type is identified based on the graph element types associated with the query requirements.

[0021] Optional, also includes: Obtain the execution result of the graph query statement; Based on the execution results, the quality of the graph query statement is verified.

[0022] Optionally, the step of performing quality verification on the graph query statement based on the execution result includes: Based on the execution results and verification rules, the graph query statement is subjected to quality verification. If verification cannot be performed based on the aforementioned verification rules, then the graph query statement is quality verified using a large language model.

[0023] Optional, also includes: If the verification passes, the query request and the graph query statement will be treated as historical query requests.

[0024] Optional, also includes: Store the processing results of each processing stage; If the verification fails, the error type is determined based on the error message; the process returns to the processing stage corresponding to the error type, and the corresponding processing procedure is re-executed based on the processing result of the previous processing stage.

[0025] Optional, also includes: Get suggestions for improvement and / or historical reasons for failures; The step of re-executing the corresponding processing procedure based on the processing result of the previous processing stage includes: Based on the results of the previous processing stage, as well as improvement suggestions and / or reasons for historical failures, the corresponding processing procedure is re-executed.

[0026] This application provides a natural language to query language method, including: Obtain data query requirements expressed in natural language, with data sources including those other than graph databases; Based on the semantic name and encoded name of the data object type, obtain the encoded name of the target data object type whose semantic name matches the query keywords; Based on the encoded name of the target data object type and the query requirements, a query statement corresponding to the query requirements is generated using a large language model.

[0027] This application provides a query language generation apparatus, comprising: The query requirement acquisition unit is used to acquire graph database query requirements expressed in natural language. The terminology mapping unit is used to obtain the target graph element type whose semantic name matches the query keyword, based on the semantic name of the graph element type. The syntax mapping unit is used to generate a graph query statement corresponding to the query requirement through a large language model, based on the encoded name of the target graph element type and the query requirement.

[0028] This application provides an electronic device, including: Processor; and A memory for storing a program for implementing the method described in any of the preceding methods, wherein the device is powered on and the program of the method is executed by the processor.

[0029] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the various methods described above.

[0030] This application also provides a computer program product including instructions that, when run on a computer, cause the computer to perform the various methods described above.

[0031] Compared with the prior art, this application has the following advantages: The query language generation method provided in this application obtains a graph database query requirement expressed in natural language; obtains a target graph element type whose semantic name matches the query keywords based on the semantic name and encoded name of the graph element type; and generates a graph query statement corresponding to the query requirement using a large language model based on the encoded name of the target graph element type and the query requirement. This approach allows the large language model to convert natural language into graph query language based on the graph element type (schema subset) matching the query requirement, avoiding the need for the large language model to generate graph query language from the complete schema. This significantly reduces the solution space of the large language model and minimizes attention distraction caused by schema information overload, thus effectively improving the accuracy of converting natural language into graph query language. Attached Figure Description

[0032] Figure 1 This is a flowchart illustrating an embodiment of the query language generation method provided in this application; Figure 2 This is a schematic diagram illustrating the specific process of an embodiment of the query language generation method provided in this application. Detailed Implementation

[0033] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0034] This application provides a query language generation method and apparatus, as well as an electronic device. The various solutions are described in detail below in each embodiment.

[0035] First Embodiment Please refer to Figure 1 This is a flowchart of the query language generation method of this application. In this embodiment, the method may include the following steps: Step S101: Obtain the graph database query requirements expressed in natural language.

[0036] The method provided in this application is used to convert natural language into a graph query language (such as nGQL) in a scenario where a graph database employs a encoded schema. The execution entity of this method can be a graph database intelligent query system.

[0037] Graph databases are databases specifically designed for storing and processing graph structures, enabling efficient relational queries by directly storing relationships between entities. The data model (schema) of a graph database includes node types (tags), edge types (edges), and their attributes. Nodes represent entities, node types are entity types, and nodes are instances of node types. Nodes typically contain a unique identifier and a set of attributes that describe the node's characteristics. Edges represent relationships between nodes, edge types are entity relationship types, and edges are instances of edge types. Edges typically contain a unique identifier, a source node, a target node, and a set of attributes; attributes describe the edge's characteristics, such as the relationship type and weight.

[0038] For ease of description, this application refers to nodes and edges in the graph database collectively as graph elements (graph data elements), and node types and edge types collectively as graph element types. For example, the node is the entity "bank card 662610000000", and the corresponding node type is "bank card"; the node is the entity "mobile phone number 13800138000", and the corresponding node type is "mobile phone number / SIM card"; the edge is the "relationship between bank card 662610000000 and mobile phone number 13800138000", and the corresponding edge type (relationship type) is "relationship between mobile phone number and bank card".

[0039] From the perspective of graph database content, its applications include highly interconnected data processing such as social network analysis and fraud prevention. In a social network, a node can represent a user, whose attributes may include username, organization, etc.; relationships between nodes can be friend relationships between users, whose attributes may include the time the relationship was established, intimacy, etc. In fraud prevention scenarios, financial transaction networks can be represented by graph structures, where nodes represent accounts or entities, and relationships between nodes can be transaction relationships. By analyzing the node connections and transaction patterns in the transaction graph, potential fraudulent or money laundering activities can be discovered. For example, banks use graph databases to store information about their customers, accounts, and transactions. Graph databases are queried to detect suspicious behavioral patterns, such as a sudden increase in transactions from a specific account or a series of transactions all related to the same person.

[0040] From the perspective of graph database schema, this embodiment applies to graph databases using a coded graph schema. In practical applications, for security, compliance, and system integration needs, graph databases uniformly convert the data structure specifications describing nodes, relationships, and attributes into coded forms for management. These coded names (schema names) of graph element types are used instead of human-readable semantic names. For example, the coded name for the node type "phone number" is "eba_object_data_102001", not the semantic name "mobile_phone"; the coded name for the node type "ID card" is "eba_object_data_101001", not the semantic name "identity_card"; and the coded name for the relationship type "association between phone number and ID card" is "eba_link_data_sjysgx_0001", not the semantic name "mobile_to_identity".

[0041] In graph databases employing encoded schemas, converting natural language into a graph query language (such as nGQL) involves not only syntax transformation but also mapping entity types expressed in natural language to encoded entity type names, and relation types expressed in natural language to encoded relation type names. For example, a natural language query for "querying the mobile phone number associated with ID card 330102xxxx" corresponds to the following graph query statement: MATCH (n:`eba_object_data_101001`)-[e]->(m:`eba_object_data_102001`) WHERE n.`eba_object_data_101001`.identity_no == "330102xxxx"RETURN m.

[0042] Step S103: Based on the semantic name and encoded name of the graph element type, obtain the encoded name of the target graph element type whose semantic name matches the query keyword.

[0043] The method provided in this application decomposes the process of bridging the dual semantic gap between natural language and graph query language into multiple specialized stages. Each stage focuses on solving a sub-problem, achieving phased semantic bridging towards a coded graph schema. Step S103 bridges the mapping gap by mapping the entity types expressed in natural language in the query request to the coded names of entity types in the graph database (standard schema terminology), and mapping the relation types expressed in natural language in the query request to the coded names of relation types in the graph database. Step S105 bridges the syntax gap by using schema-aware query generation. That is, based on the semantic names of graph element types obtained in step S103 and the coded names of target graph element types that match the query keywords, the query request is converted into a graph query statement that conforms to the syntax rules.

[0044] In one example, step S103 can be implemented as follows: based on the semantic name and encoded name of the graph element type, obtain the encoded name of the first target graph element type whose semantic name matches the text of the query keyword.

[0045] In practice, the following "Graph Element Type Name" registry (also known as the "Terminology" registry or rule dictionary) can be configured:

[0046] Table 1. Terminology Registry In practical implementation, the system can decouple the standard naming system from the underlying graph database through a schema adaptation layer. Each standard structure maintains mapping relationships between multiple data sources (including data source type, schema name, mapping type, etc.). By switching adaptation layers, different graph databases (such as Neo4j / Cypher, TigerGraph / GSQL, etc.) can be supported. The core terminology mapping, intent recognition, and reflective correction logic do not need to be modified, thus achieving multi-graph database adaptation.

[0047] In practice, the standard name data source mapping supports multiple types (graph database, relational database, search engine, etc.). The same user query can be mapped to the schema of different data sources at the same time, providing a basis for cross-data source joint queries and realizing the integration of multiple data sources.

[0048] In practice, based on the semantic name and coded name of the graph element type, the coded name of the first target graph element type that matches the text of the query keyword can be obtained. The following process can be adopted: obtain one or more query keywords included in the query requirements; for each query keyword, retrieve the coded name of the graph element type that matches the semantic name of the graph element type in the text of the query keyword in the Term Registry, and use the coded name of the graph element type that matches the text as the coded name of the first target graph element type.

[0049] The semantic name of a graph element type can be the standard name of the graph element type, a list of aliases for the graph element type, or a combination of both. In practice, a case-insensitive exact match can be performed using the forward index of the term registry, with the matching scope including both the standard name and the alias list.

[0050] The method provided in this application embodiment obtains the encoding name of the first target graph element type whose semantic name matches the text of the query keyword based on the semantic name and encoding name of the graph element type, thereby achieving precise matching of the rule dictionary. This mapping method is the fastest (O(1) hash lookup), has higher accuracy, and a confidence level of 0.90 to 1.00.

[0051] In one example, step S103 can be implemented as follows: based on the semantic name and encoded name of the graph element type, obtain the encoded name of the second target graph element type whose semantic name is similar to the character-level semantics of the query keyword.

[0052] Character-level semantic similarity can be character-level N-gram semantic similarity, such as character-level binary Bigram vector similarity, character-level ternary Trigram vector similarity, etc. In specific implementation, based on the semantic name and encoded name of the graph element type, the encoded name of the second target graph element type whose semantic name is semantically similar to the query keyword at the character level can be obtained. This can be achieved through the following process: converting the query keyword and the semantic name of the graph element type into character-level Bigram vectors and performing L2 normalization, then calculating the matching degree using cosine similarity; selecting the encoded names of multiple graph element types whose semantic names are semantically similar to the query keyword at the character level (Top-3), and using these as the encoded names of the second target graph element type.

[0053] Taking the query keyword "phone number" and the candidate semantic name "phone" as an example: the character-level Bigram set of the query keyword "phone number" is {"phone":1, "phone number":1}, and the L2 normalized vector is {"phone":0.707, "phone number":0.707}; the character-level Bigram set of the candidate semantic name "phone" from Table 1 above is {"phone": 1}, and the L2 normalized vector is {"phone":1.0}; the cosine similarity between the query keyword "phone number" and the candidate semantic name "phone" is 0.707 × 1.0 = 0.707. This similarity exceeds the threshold of 0.6, so the text matching is successful. According to the table above, the encoding name of the second target graph element type that matches the query keyword "phone number" is "eba_object_data_102001".

[0054] The method provided in this application embodiment obtains the encoded name of a second target graph element type whose semantic name is similar to the character-level semantics of the query keyword based on the semantic name and encoded name of the graph element type. This method can cover synonyms and variant expressions of the query keyword, with a confidence level of 0.70 to 0.94.

[0055] In one example, step S103 can be implemented as follows: based on the graph pattern, obtain the semantic names of multiple graph element types; through a large language model, based on the semantic names of multiple graph element types, obtain the encoded name of a third target graph element type whose semantic name is semantically similar to the query keyword from the multiple graph element types.

[0056] In practice, based on the graph pattern, multiple graph element types can be obtained in the following way: select a preset number of semantic names for graph element types from the terminology mapping table mentioned above. For example, select 20 semantic names for graph element types from 100 semantic names for graph element types.

[0057] In practice, in addition to sending the semantic names of the selected graph element types to the large language model, the schema names (encoded names) and descriptions of the graph element types can also be sent to the large language model for semantic inference.

[0058] The method provided in this application selects the semantic names of multiple graph element types from the graph pattern and sends them to a large language model for semantic inference fallback. The large language model obtains the encoded name of a third target graph element type whose semantic name is similar to that of the query keyword from the multiple graph element types. This method has higher coverage, can handle industry jargon and implicit semantics, and the confidence level can reach 0.30 to 0.70.

[0059] like Figure 2As shown, in one example, step S103 may include the following sub-steps: Step S1031: Based on the semantic name and encoded name of the graph element type, obtain the encoded name of the first target graph element type whose semantic name matches the text of the query keyword.

[0060] Step S1032: If there is no encoded name for the first target graph element type, then based on the semantic name and encoded name of the graph element type, obtain the encoded name of the second target graph element type whose semantic name is similar to the character-level semantic name of the query keyword.

[0061] Step S1033: If there is no encoded name for the second target graph element type, obtain the semantic names of multiple graph element types according to the graph pattern; through the large language model, obtain the encoded name of the third target graph element type whose semantic name is similar to the semantic name of the query keyword from the multiple graph element types.

[0062] This three-layer progressive retrieval strategy employs a rule dictionary for precise matching, followed by character-level n-gram semantic similarity and then LLM semantic inference as a fallback. The three layers are attempted sequentially from high to low confidence, stopping once a match is found. The layers are in a serial degradation relationship rather than a parallel combination relationship, ensuring that over 80% of common semantic names can be mapped at the first layer (text matching), effectively balancing efficiency and coverage.

[0063] For example, if a user's query includes the keyword "serial number" (the actual standard name in the terminology mapping table is "transaction log"), the processing steps in step S103 are as follows: Level 1: A precise search for "serial number" is performed in the terminology registry. Since there is no such name or alias as "serial number" in the registry, no match is found, and the process proceeds to Level 2. Level 2: The Bigram similarity is calculated. Among all candidates, "transaction log" has the highest similarity (0.52), which is below the threshold of 0.6. Therefore, no candidate passes the threshold, and the process proceeds to Level 3. Level 3: Twenty standard names ["phone number", "bank card", "transaction log", "IP address", ...] are taken and sent to the large language model. The large language model infers that "serial number" most likely corresponds to "transaction log" with a confidence level of 0.55.

[0064] In one example, step S103 may further include the following sub-step 1034: If the query keyword is ambiguous, then according to the query requirement, select the encoding name of the target graph element type that matches the query keyword from the encoding names of multiple candidate graph element types with different meanings corresponding to the query keyword. For example, if a user queries "query the bank transaction records of this card," the query keyword "card" is ambiguous, possibly meaning "bank card" or "SIM card." "Bank card" and "SIM card" are candidate graph element types with different meanings. Based on the "bank transaction records" included in the query requirement, select the encoding name "bank card" (eba_object_data_801001) that matches "card" from the encoding names of "bank card" and "SIM card." This processing method can effectively eliminate ambiguous words with multiple meanings.

[0065] In one example, sub-step S1034 may include the following processing procedure (referred to as Dimension 1 in Table 3): obtaining a list of positive enhancement keywords and / or a list of negative exclusion keywords for candidate graph element types; increasing the confidence of candidate graph element types if the query requirement includes keywords from the positive enhancement keyword list; decreasing the confidence of candidate graph element types if the query requirement includes keywords from the negative enhancement keyword list; and selecting the encoding name of the target graph element type that matches the query keyword from multiple encoding names of candidate graph element types with different meanings, based on the adjusted confidence of the candidate graph element types. This processing method allows for the adjustment of confidence through positive enhancement keywords (positive_keywords) and negative exclusion keywords (negative_keywords).

[0066] In practice, a list of positively reinforcing keywords and a list of negatively excluding keywords can be added to the terminology mapping table, as shown in the table below:

[0067] Table 2. Terminology Registry For example, in the query "Query the bank transaction records of this card", the entities matching "card" include "bank card" and "SIM card". The initial confidence scores for both "bank card" and "SIM card" are 0.85. Since "bank card" matches "bank" in the positive reinforcement keyword list, the confidence score for "bank card" is adjusted to the initial confidence score of 0.85 + the positive reinforcement confidence score change of 0.05 = 0.9. Since "SIM card" does not match "bank card" in the negative exclusion keyword list, the initial confidence score for "SIM card" remains unchanged at 0.85. Therefore, "bank card" with a confidence score of 0.9 is selected as the entity matching "card".

[0068] In one example, sub-step S1034 may include the following processing procedure (referred to as Dimension Two in Table 3): obtaining disambiguation rules corresponding to the query keywords, wherein the disambiguation rules include a preset candidate graph element type corresponding to the query keywords, a positive enhancement keyword list for the preset candidate graph element type, and a negative exclusion keyword list; increasing the confidence of the candidate graph element type based on the number of keywords in the positive enhancement keyword list of the preset candidate graph element type included in the query requirement; decreasing the confidence of the candidate graph element type based on the number of keywords in the negative enhancement keyword list of the preset candidate graph element type included in the query requirement; and selecting the encoding name of the target graph element type matching the query keywords from multiple encoding names of candidate graph element types with different meanings based on the adjusted confidence of the candidate graph element type. This processing method enables candidate sorting through a dedicated configuration for ambiguous terms (boost_keywords / suppress_keywords).

[0069] For example, define the following disambiguation rule in the ambiguous word configuration file: "Card": { "candidates": [ {"schema_name":"eba_object_data_801001","label":"Bank Card","confidence": 0.6, "boost_keywords": ["bank","savings","credit","card number"], "suppress_keywords": ["SIM","mobile","telephone","data"]}, {"schema_name":"eba_object_data_102001","label":"SIM card","confidence":0.4, "boost_keywords": ["SIM","mobile","telephone","data","carrier"], "suppress_keywords": ["bank","savings","credit"]} ] } The disambiguation logic based on this rule is as follows: Iterate through all preset candidate graph element types (candidates) for the keyword "card", including "bank card" and "SIM card". If the candidate graph element type for the current query keyword "card" matches the preset candidate graph element type in the disambiguation rule, then check the positive boosting keyword list boost_keywords and the negative boosting keyword list suppress_keywords. For each keyword in boost_keywords matched, the confidence level increases by 0.1 (the specific change value can be set according to requirements); for each keyword in suppress_keywords matched, the confidence level decreases by 0.15 (the specific change value can be set according to requirements).

[0070] For example, the query "Query the bank transaction records of this card" matches the entities "card" including "bank card" and "SIM card". The initial confidence levels for both "bank card" and "SIM card" are 0.85. Since "bank card" matches the preset candidate graph element type "bank card" in the disambiguation rule, the positive boosting keyword list `boost_keywords` and the negative boosting keyword list `suppress_keywords` for "bank card" are checked. Because "bank" is matched in `boost_keywords`, the confidence level increases by 0.1. Similarly, since "SIM card" matches the preset candidate graph element type "SIM card" in the disambiguation rule, the positive boosting keyword list `boost_keywords` and the negative boosting keyword list `suppress_keywords` for "SIM card" are checked. Because "bank" is matched in `suppress_keywords`, the confidence level decreases by 0.15.

[0071] In practice, the system's terminology registry and disambiguation configuration can both be externalized (e.g., JSON files). When migrating to new domains (such as financial risk control, social networks, supply chain management, etc.), only the terminology configuration file and seed high-quality historical cases need to be replaced; no modification to the core process is required. The three-layer progressive retrieval architecture ensures that even when terminology coverage in a new domain is incomplete, fallback capabilities can still be provided through the second layer (n-gram similarity) and the third layer (LLM inference). This approach enables multi-domain migration.

[0072] In one example, sub-step S1034 may include the following processing procedure (referred to as dimension three in Table 3): Identify the target intent type according to the query requirement; obtain the confidence correction weights for different intent types according to the target intent type; adjust the confidence of the candidate graph element type according to the confidence correction weights for different intent types; and select the code name of the target graph element type that matches the query keyword from multiple code names of candidate graph element types with different meanings according to the adjusted confidence of the candidate graph element type.

[0073] Intent type refers to the type of query request, including but not limited to: entity query, relationship query, path query, commonality query, conditional query, aggregation query, clue tracing, multi-hop query, and comparison query. The query request is subjected to intent identification to determine which intent type it belongs to or reject it. Different intent types have different weighting coefficients for different mapping types (such as entity type, attribute type, and relationship type), and the confidence level can be adjusted using a multiplicative method.

[0074] Taking the intent type "relationship query" as an example, the weight of the graph element type corresponding to "entity type" is 1.0, the weight of the graph element type corresponding to "attribute type" is 0.8, and the weight of the graph element type corresponding to "relationship type" is 1.0. This means that the confidence of entity type mapping and relation type mapping remains unchanged (×1.0), while the confidence of attribute mapping is discounted (×0.8, because attributes are not core elements in relation queries). For example, the query keyword "card" is mapped to "bank card" and "SIM card," both of which are entity type mappings with a weight of 1.0 and unchanged confidence. If "card" is mapped to an attribute type graph element type, the confidence of the attribute type graph element type is reduced by multiplying the confidence by 0.8.

[0075] The method provided in this application identifies the target intent type of the query request; adjusts the weights based on the confidence of different intent types corresponding to the target intent type, and adjusts the confidence of multiple candidate graph element types with different meanings corresponding to the query keywords; based on the adjusted confidence of the candidate graph element types, selects the encoded name of the target graph element type that matches the query keywords from the encoded names of multiple candidate graph element types with different meanings. This processing method allows the confidence of different mapping types to be adjusted through intent type weight constraints (INTENT_MAPPING_WEIGHTS).

[0076] In one example, identifying the target intent type based on the query requirement can be achieved as follows: obtain the graph element types related to the query requirement; and identify the target intent type based on the graph element types related to the query requirement using a large language model.

[0077] In practice, keywords can be extracted from the query requirements. The query keywords are then matched with the standard names and aliases of each entity class diagram element type (such as "bank card" or "ID card") in the graph database schema. The top K most relevant entity class diagram element types (e.g., default K=10) are selected based on the scores, as well as the associated relationship class diagram element types (default K=20). The attribute definitions of the selected entity class diagram element types can be dynamically loaded from the metadata table.

[0078] The method provided in this application uses a schema-based intelligent filtering approach to identify graph element types relevant to the query requirements. The prompt given to the large language model only includes the graph element types most relevant to the current query (a subset of schemas, typically 1-5 entity class graph element types), rather than the complete set of entity class graph element types (such as the complete 19 entity class graph element types). This processing method ensures that the LLM only sees the actual schema information, significantly reducing the attentional distraction of the large language model and fundamentally eliminating schema illusion; therefore, it can effectively improve the accuracy of intent type identification.

[0079] In one example, sub-step S1034 may include the following processing procedure (referred to as Dimension 4 in Table 3): obtaining the historical success rate of mapping query keywords to candidate graph element types; adjusting the confidence of candidate graph element types based on the historical success rate; and selecting the encoding name of the target graph element type matching the query keywords from multiple encoding names of candidate graph element types with different meanings based on the adjusted confidence of the candidate graph element types. For example, if the historical mapping success rate of "card" → "bank card" (eba_object_data_801001) is 0.85, then the confidence of "bank card" is adjusted to: 0.7 × current confidence + 0.3 × 0.85. In specific implementation, an exponentially weighted moving average (EMA) method can be used to learn the historical mapping results, giving recent data a higher weight by assigning exponentially decaying weights to historical data. Using this processing method, the confidence of candidate graph element types is determined by combining historical mapping success rates; therefore, the accuracy of confidence can be further improved, thereby improving disambiguation performance.

[0080] In practical applications, the above-mentioned disambiguation methods can be used to eliminate ambiguous words with multiple meanings. For example, in the query "Query the bank transaction records of this card", assuming that the initial confidence level of "card" → "bank card" and "SIM card" is 1.0, the adjustment process of the confidence level of "bank card" and "SIM card" is shown in the table below:

[0081]

[0082] Based on the content of the table above, since the confidence score of "bank card" (0.99) is greater than that of "SIM card" (0.85), the result of step S103 is to map the query keyword "card" to "bank card" (eba_object_data_801001). It can be seen that by using the intent context disambiguation mechanism in the three-layer progressive retrieval, and employing four dimensions—positive / negative keywords, dedicated configuration for ambiguous terms, intent type weight constraints, and EMA confidence learning—disambiguation can accurately distinguish the meaning of the same query keyword (term) in different contexts, overcoming the problem of polysemy.

[0083] Step S105: Based on the encoded name of the target graph element type and the query requirement, generate a graph query statement corresponding to the query requirement using a large language model.

[0084] This step bridges the grammatical gap by generating schema-aware queries. Specifically, it converts the query requirements into a grammatically correct graph query statement by matching the semantic names of the graph element types obtained in step S103 with the encoded names of the target graph element types that match the query keywords.

[0085] In one example, step S105 can be implemented as follows: Based on the encoded name of the target graph element type and the query requirement, generate a prompt from the large language model; then, using the large language model, generate a graph query statement corresponding to the query requirement based on the prompt. This approach allows the large language model to generate a graph query statement corresponding to the current query requirement based on a unified natural language-to-graph query statement example; therefore, it can effectively reduce development costs.

[0086] In another example, step S105 may include the following sub-steps: Step S1051: Obtain historical query requests similar to the stated query request.

[0087] Step S1053: Based on the encoded name of the target graph element type, the query requirement, and the graph query statements of similar historical query requirements, generate a graph query statement corresponding to the query requirement using a large language model.

[0088] In practice, historical query requests similar to the current query request and their corresponding graph query statements (hereinafter referred to as historical cases) can be injected into the "Similar Historical Case Reference" section of the large language model prompt as dynamic few-shot injection examples. A small number of examples are provided in the Prompt to guide the generation of the large language model. The large language model prompt also includes a "Query Request" section and a "Code Name of Target Graph Element Type" section.

[0089] By employing this RAG (Retrieval-Augmented Generation) dynamic few-shot injection method, the generation quality of the large language model is enhanced by retrieving external knowledge bases. Each query obtains more relevant reference cases rather than fixed general examples. The large language model references historical query requirements similar to the current query requirements to convert them into graph query statement cases, generating graph query statements corresponding to the current query requirements. Therefore, the generation accuracy can be effectively improved.

[0090] In one example, step S1051 can be implemented as follows: Identify the target intent type based on the query requirement; obtain eligible historical query requirements based on the target intent type, the review status of historical query requirements, and / or the processing stage of historical query requirements; select historical query requirements semantically similar to the current query requirement from the eligible historical query requirements. The intent type ensures that the retrieveable historical cases belong to the same intent type as the current query; the processing stage ensures that the historical cases are applicable to the currently executing processing stage, such as query generation or element extraction; the review mechanism ensures that only high-quality cases that have undergone manual review can be injected, avoiding contamination by erroneous cases. In specific implementation, the semantic vector of the historical query requirement can be determined solely based on the historical query requirement. This processing method allows for multi-dimensional filtering of historical cases based on the intent type of the historical query requirement, and at least one of the processing stage and review status of the historical query requirement, such as filtering historical cases with the intent type of relational query, applicable to the query generation stage, or already reviewed; and selecting historical query requirements semantically similar to the current query requirement from the filtered historical query requirements. Therefore, it can effectively improve the matching degree between similar historical cases and current query needs, thereby improving the generation accuracy of graph query language.

[0091] For example, suppose a user's current query is "to query bank cards associated with mobile number 13800138000", with the intent being a "relationship query", and the query is currently in the generation stage. The method provided in this application embodiment retrieves data in the following manner: 1. Filtering criteria: Review status = Reviewed + Intent type = Relationship query + Processing stage = Query generation stage 2. Vector Similarity Ranking: In the filtered case set, sort by semantic vector similarity according to the current query requirements. 3. Return the historical cases with the highest semantic similarity: take the top K most similar cases (e.g., K=3).

[0092] Using the search method described above, the following are some examples of historical cases retrieved: Historical Case 1: Query request: "Query the mobile phone number associated with ID card number 330102xxxx" Intent type: query_relationship nGQL: MATCH (n:`eba_object_data_101001`)-[e]->(m:`eba_object_data_102001`) WHERE n.`eba_object_data_101001`.identity_no ==="330102xxxx"RETURNm Historical Case 2: Query requirement: "Query the IP address associated with bank card 6222xxxx" Intent: query_relationship nGQL: MATCH (n:`eba_object_data_801001`)-[e]->(m:`eba_object_data_201001`) WHERE n.`eba_object_data_801001`.card_no == "6222xxxx"RETURN m These cases are formatted and injected into the "Similar Historical Case Reference" section of the Prompt, providing a structural reference for LLM to generate graph query statements for the current query requirements.

[0093] In one example, selecting historical query requests semantically similar to the current query request from eligible historical query requests can be achieved as follows: Based on the historical query request, its graph query statement, and the target intent type, determine the semantic vector of the historical query request; based on the semantic vector of the historical query request, select historical query requests semantically similar to the current query request from the eligible historical query requests. This approach ensures that the semantic vector of the historical query request is a combination of the query request, intent type, and query statement, effectively enhancing the semantic distinguishability of the retrieval. For example, "query bank cards associated with a mobile phone number" (relationship query) and "query the number of mobile phone numbers" (aggregation query) have similar query text, but their intents and generated query statements are completely different. By combining the intent type and query statement, the vector can better distinguish different types of cases in the semantic space, improving retrieval accuracy.

[0094] In practice, historical cases can be stored in a vector database. Each case can contain the following structured fields: original query requirement, intent type, semantic vector of the query requirement, processing stage, review status (reviewed or unreviewed), complete case data serialized in JSON format, and creation timestamp. The vector index uses an approximate nearest neighbor index (such as IVF_FLAT) combined with cosine similarity measurement. The semantic vector of historical query requirements can be calculated as follows: 1) The query requirement is converted into a high-dimensional dense vector through a semantic vector encoding model; 2) The semantic vector of historical query requirements (vectorized query requirements) is a combination of query requirement, intent type, and graph query statement to enhance the semantic distinguishability of the retrieval. The complete case data serialized in JSON format can contain the complete context of the case (extracted elements, generated query statement, execution results, etc.), and after formatting, it is injected into the Prompt as a Few-shot example. The creation timestamp can be used for case management and sorting, and can support adjusting the retrieval weight by time decay.

[0095] In one example, step S105 may include the following sub-steps: Step S1051': Obtain structured query elements based on the coded name of the target graph element type and the query requirements.

[0096] Step S1053': Using a large language model, generate a graph query statement corresponding to the query requirements based on the structured query elements.

[0097] This processing method allows for the extraction of structured query elements based on the mapping results of each query keyword obtained in step S103. These query elements include entity type, attribute name, attribute value, target entity, and relation type. This provides structured query elements to the large language model, enabling it to directly generate graph query statements based on these elements; thus, it effectively improves generation efficiency and accuracy.

[0098] In one example, step S1051' can be implemented as follows: 1. Based on the query requirements, determine the source graph element type as the query condition element and the target graph element type as the query target from multiple target graph element types that match multiple query keywords respectively; 2. Using a large language model, extract the attribute values ​​corresponding to the source attribute names as query condition elements from the query requirements. This approach allows for two paths to obtain structured query elements: 1. Preferred path: Directly construct query elements using the mapping results (target graph element types) from step S103, without requiring a large language model, offering high determinism and avoiding the LLM illusion; 2. Fallback path: Only call the LLM to extract and supplement information from the natural language query requirements when information (such as attribute values) is missing.

[0099] The following complete example will provide a more intuitive explanation of how to extract query elements. For instance, a user queries: "Query bank cards associated with mobile phone number 13800138000"; 1. Mapping result of step S103: ①"Mobile number" → eba_object_data_102001 (entity type, confidence level 0.95); ② "Bank Card" → eba_object_data_801001 (Entity type, confidence level 0.92) 2. Step S1051: The process of extracting structured query elements based on the mapping results of step S103. ① Rule-based construction: The source entity's type (entity_type) is ="eba_object_data_102001" The source entity's attribute name (entity_key) is "mobile". The type of the target entity (target_entity) is "eba_object_data_801001". Relationship type (relationship_type) = None ②LLM supplementary extraction (only for missing information): The source entity's attribute value (entity_value) is ="13800138000". The final output structured query elements: { "entity_type":"eba_object_data_102001", "entity_key":"mobile", "entity_value":"13800138000", "source_entity": {"type":"eba_object_data_102001","key":"mobile","value":"13800138000"}, "target_entity": {"type":"eba_object_data_801001","key":"card_no","value": null}, "relationship_type": null, "max_hops": 1 } In one example, the method provided in this application embodiment may further include the following steps: Step S201: Obtain the execution result of the graph query statement.

[0100] This step executes the graph query statement. In practice, it connects to the graph database and executes the graph query statement generated in step S105 through connection pool management and automatic retry mechanisms to obtain the query results.

[0101] Step S203: Based on the execution result, perform quality verification on the graph query statement.

[0102] This step verifies the quality of the graph query statement based on its execution record. Specifically, step S203 may include the following sub-steps: Step S2031: Perform quality verification on the graph query statement based on the execution result and verification rules.

[0103] Based on validation rules, rapid quality validation can be achieved. For example, validation rules (in order of priority) may include: 1. Execution error exists → Validation fails (quality score 0.0); 2. Query result is empty → Validation fails; 3. The "Query success or failure" field in the result is "failed" → Validation fails; 4. The "error" field exists in the result → Validation fails; 5. Number of rows returned > 0 → Validation passes, quality score = min(0.9, 0.7 + number of rows × 0.02).

[0104] Step S2033: If verification cannot be performed based on the verification rules, then the graph query statement is quality verified using a large language model.

[0105] When the fast rule cannot determine the result (e.g., returning 0 rows but no error), LLM is invoked for deep validation. Experiments have shown that in most cases, the LLM call can be skipped, reducing the single validation latency from ~2s to <10ms, significantly reducing latency and cost.

[0106] The method provided in this application embodiment, through steps S2031 and S2033, realizes a two-layer strategy of fast rule verification + LLM deep verification to verify the quality of query results.

[0107] In one example, the method provided in this application embodiment may further include the following steps: if the verification is successful, the query requirement and the graph query statement are treated as historical query requirements. This approach allows verified current query cases to be stored as historical cases in a historical case library, providing a richer pool of historical cases for subsequent user queries. Specifically, if the administrator approves the current query case, the approval status is set to "approved," enabling subsequent queries to retrieve and inject it into the Prompt, forming a continuous learning flywheel. This ensures a quality-controlled self-evolution of the Prompt, achieving continuous system evolution.

[0108] In one example, the method provided in this application embodiment may further include the following steps: Step S301: Store the processing results of each processing stage.

[0109] The method provided in this application uses a multi-stage divide-and-conquer architecture to decompose the NL2GQL task into multiple specialized independent stages, such as schema intelligent filtering, intent recognition, schema terminology mapping, three-layer progressive terminology retrieval, four-dimensional intent disambiguation, structured query element extraction, query generation, and reflective correction. The processing results of each stage are stored in a global state dictionary, which is used to transfer information between stages, and conditional routing is used to achieve adaptive execution path control. In specific implementation, after each processing stage is completed, a snapshot of the current global state dictionary is automatically saved using an InMemorySaver.

[0110] Step S303: If the verification fails, determine the error type based on the error message.

[0111] This step involves differentiating different types of errors based on the error message when a query fails, such as intent misunderstanding errors, term mapping errors, and syntax errors.

[0112] In practical implementation, by storing the processing results of each processing stage, it is possible to support the backtracking of the processing results at each stage. That is, in the reflection and correction stage, the executing entity of the method can backtrack to the state of any historical checkpoint and obtain the complete context information of that stage (such as the terminology mapping results, schema filtering results, etc. at that time), providing a complete decision basis for error analysis. In practical implementation, LLM can be used to analyze the causes of failure and classify error types.

[0113] Step S305: Return to the processing stage corresponding to the error type, and re-execute the corresponding processing procedure based on the processing result of the previous processing stage.

[0114] This step adaptively decides to roll back to different stages based on the error type (Schema usage error vs. query logic error).

[0115] In practical implementation, by storing the processing results of each processing stage, execution backtracking can be supported. That is, in the reflection and correction stage, the execution subject of the method can backtrack to the state of any historical checkpoint, obtain the complete context information of that stage (such as the term mapping result, schema filtering result, etc. at that time), and re-execute the processing stage corresponding to the error type according to the processing result of the previous processing stage corresponding to the error type, so as to achieve targeted repair.

[0116] In one example, when validation fails and the number of retries has not reached the maximum (default 3), the system enters a reflexive correction phase. LLM analyzes the reasons for failure and categorizes error types, adaptively deciding on the fallback point based on the error type:

[0117] In one example, the method provided in this application embodiment may further include the following steps: obtaining improvement suggestions and / or historical failure reasons; step S305 can be implemented as follows: based on the processing result of the previous processing stage, and the improvement suggestions and / or historical failure reasons, re-execute the corresponding processing procedure. In specific implementation, the reflection results (including error analysis, improvement suggestions, and reflection history) can be injected as context into the Prompt of the rollback stage, enabling the LLM to refer to historical failure reasons to avoid repeating mistakes. This is combined with a checkpoint mechanism to achieve breakpoint resumption and execution backtracking.

[0118] In practical implementation, by storing the processing results of each processing stage, it can also support breakpoint resumption. That is, when the process is interrupted due to abnormal situations such as network interruption or service restart, execution can be resumed from the nearest checkpoint without having to start from the beginning, thus avoiding the waste of time and cost caused by repeatedly calling LLM.

[0119] The method provided in this application, through steps S301 to S305, distinguishes different types of errors. Errors at each stage can be independently identified and repaired. The adaptive reflection and correction mechanism intelligently decides to revert to the element extraction or query generation stage based on the error type, rather than blindly regenerating. Therefore, it can effectively improve the system's accuracy, reliability, and evolvability.

[0120] As can be seen from the above embodiments, the query language generation method provided in this application obtains the query requirements of a graph database expressed in natural language; obtains the target graph element type whose semantic name matches the query keywords based on the semantic name and encoded name of the graph element type; and generates a graph query statement corresponding to the query requirements through a large language model based on the encoded name of the target graph element type and the query requirements. This processing method allows the large language model to convert natural language into graph query language based on the graph element type (schema subset) matching the query requirements, avoiding the need for the large language model to generate graph query language based on the complete schema. This significantly reduces the solution space of the large language model and reduces the attention distraction caused by schema information overload, thus effectively improving the accuracy of converting natural language into graph query language.

[0121] Second Embodiment In the above embodiments, a query language generation method is provided. Correspondingly, this application also provides a query language generation apparatus. This apparatus corresponds to the embodiments of the method described above. Since the apparatus embodiments are basically similar to the method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments. The apparatus embodiments described below are merely illustrative.

[0122] This application also provides a query language generation device, including: a query requirement acquisition unit, a term mapping unit, and a syntax mapping unit.

[0123] The query requirement acquisition unit is used to acquire the graph database query requirements expressed in natural language; the terminology mapping unit is used to acquire the target graph element type whose semantic name matches the query keyword based on the semantic name of the graph element type; and the syntax mapping unit is used to generate a graph query statement corresponding to the query requirement through a large language model based on the encoded name of the target graph element type and the query requirement.

[0124] In one example, the term mapping unit includes a text matching subunit for obtaining the encoded name of a first target graph element type whose semantic name matches the query keyword, based on the semantic name and encoded name of the graph element type.

[0125] In one example, the term mapping unit includes a character-level semantic matching subunit, which, if no encoded name for the first target graph element type exists, obtains the encoded name of the second target graph element type whose semantic name is similar to the character-level semantic name of the query keyword, based on the semantic name and encoded name of the graph element type.

[0126] In one example, the term mapping unit includes a large language model semantic inference subunit, which is used to obtain the semantic names of multiple graph element types based on the graph pattern if there is no encoded name for the second target graph element type; and to obtain the encoded name of the third target graph element type whose semantic name is semantically similar to the query keyword from the multiple graph element types based on the semantic names of the multiple graph element types through the large language model.

[0127] In one example, the term mapping unit includes a deambiguity subunit, which, if the query keyword is polysemous, selects the encoded name of the target graph element type that matches the query keyword from a pool of candidate graph element type encoded names with different meanings corresponding to the query keyword, based on the query requirements.

[0128] In one example, the disambiguation subunit includes a first disambiguation subunit, used to obtain a list of positive enhancing keywords and / or a list of negative excluding keywords for candidate graph element types; if the query requirement includes keywords from the list of positive enhancing keywords, the confidence of the candidate graph element type is increased; if the query requirement includes keywords from the list of negative enhancing keywords, the confidence of the candidate graph element type is decreased; based on the adjusted confidence of the candidate graph element type, the encoded name of the target graph element type matching the query keyword is selected from the encoded names of multiple candidate graph element types with different meanings.

[0129] In one example, the disambiguation subunit includes a second disambiguation subunit, used to obtain disambiguation rules corresponding to the query keywords. These disambiguation rules include a preset candidate graph element type corresponding to the query keywords, a list of positively reinforcing keywords for the preset candidate graph element type, and a list of negatively excluding keywords. Based on the number of keywords in the list of positively reinforcing keywords for the preset candidate graph element type included in the query requirement, the confidence of the candidate graph element type is increased. Based on the number of keywords in the list of negatively reinforcing keywords for the preset candidate graph element type included in the query requirement, the confidence of the candidate graph element type is decreased. Based on the adjusted confidence of the candidate graph element type, the encoded name of the target graph element type matching the query keywords is selected from multiple encoded names of candidate graph element types with different meanings.

[0130] In one example, the disambiguation subunit includes a third disambiguation subunit, used to identify the target intent type according to the query requirements; obtain confidence correction weights for different intent types according to the target intent type; adjust the confidence of candidate graph element types according to the confidence correction weights for different intent types; and select the encoding name of the target graph element type that matches the query keywords from multiple encoding names of candidate graph element types with different meanings according to the adjusted confidence of the candidate graph element types.

[0131] In one example, the disambiguation subunit includes a fourth disambiguation subunit, which is used to obtain the historical success rate of mapping query keywords to candidate graph element types; adjust the confidence of candidate graph element types based on the historical success rate; and select the encoding name of the target graph element type that matches the query keywords from multiple encoding names of candidate graph element types with different meanings based on the adjusted confidence of the candidate graph element types.

[0132] In one example, the syntax mapping unit includes: a feature extraction subunit. The feature extraction subunit is used to obtain structured query features based on the encoded names of the target graph element types and the query requirements; the statement generation subunit is used to generate a graph query statement corresponding to the query requirements based on the structured query features using a large language model.

[0133] In one example, the feature extraction subunit is specifically used to determine the source graph element type as the query condition element and the target graph element type as the query target from multiple target graph element types that match multiple query keywords, according to the query requirements; and to extract the attribute values ​​corresponding to the source attribute names as query condition elements from the query requirements through a large language model.

[0134] In one example, the apparatus further includes: a similar historical case acquisition unit, used to acquire historical query requests similar to the query request; and a syntax mapping unit, specifically used to generate a graph query statement corresponding to the query request through a large language model based on the encoded name of the target graph element type, the query request, and the graph query statements of the similar historical query requests.

[0135] In one example, the similar historical case acquisition unit includes: an intent identification subunit, a case filtering subunit, and a semantic matching subunit. The intent identification unit is used to identify the target intent type based on the query requirement; the case filtering unit is used to obtain historical query requirements that meet the criteria based on the target intent type, the review status of historical query requirements, and / or the processing stage of historical query requirements; the semantic matching subunit is used to select historical query requirements that are semantically similar to the query requirement from the qualified historical query requirements.

[0136] In one example, the semantic matching subunit is specifically used to determine the semantic vector of the historical query requirement based on the historical query requirement, the graph query statement of the historical query requirement, and the target intent type of the historical query requirement; and to select historical query requirements with similar semantics to the query requirement from the historical query requirements that meet the conditions based on the semantic vector of the historical query requirement.

[0137] In one example, the intent recognition subunit is specifically used to obtain the graph element types related to the query request; and to identify the target intent type based on the graph element types related to the query request using a large language model.

[0138] In one example, the apparatus further includes: a statement execution unit and a statement quality verification unit. The statement execution unit is used to obtain the execution result of the graph query statement; the statement quality verification unit is used to perform quality verification on the graph query statement based on the execution result.

[0139] In one example, the statement quality verification unit is specifically used to perform quality verification on the graph query statement based on the execution result and verification rules; if verification cannot be performed based on the verification rules, the graph query statement is then verified using a large language model.

[0140] In one example, the apparatus further includes a case accumulation unit, used to treat the query request and the graph query statement as historical query requests if the verification passes.

[0141] In one example, the device further includes: a global data storage unit, a reflection unit, and a correction unit. The global data storage unit is used to store the processing results of each processing stage; the reflection unit is used to determine the error type based on the error information if the verification fails; the correction unit is used to return to the processing stage corresponding to the error type and re-execute the corresponding processing procedure based on the processing result of the previous processing stage.

[0142] In one example, the apparatus further includes: a reflection result acquisition unit for acquiring improvement suggestions and / or historical failure reasons; and a correction unit specifically for re-executing the corresponding processing procedure based on the processing results of the previous processing stage, as well as the improvement suggestions and / or historical failure reasons.

[0143] Third Embodiment In the above embodiments, a query language generation method is provided. Correspondingly, this application also provides a query language generation method. This method corresponds to the embodiments of the above methods. Since this embodiment is basically similar to the first method embodiment, it is described simply. For relevant details, please refer to the description of the first method embodiment. The method embodiments described below are merely illustrative.

[0144] The query language generation method in this embodiment includes the following steps: Step S401: Obtain the data query requirements expressed in natural language, including data sources other than graph databases.

[0145] The difference between this embodiment and Method Embodiment 1 is that Method Embodiment 1 targets a graph database as its data source, while this embodiment targets data sources other than graph databases. Data sources other than graph databases include, but are not limited to, relational databases and search engines. These data sources can all use encoded schema names.

[0146] Step S403: Based on the semantic name and encoded name of the data object type, obtain the encoded name of the target data object type whose semantic name matches the query keyword.

[0147] The data source includes multiple data objects, which are instances of data object types. The name of the data object type in the data model schema is the coded name.

[0148] Step S405: Based on the encoded name of the target data object type and the query requirement, generate a query statement corresponding to the query requirement using a large language model.

[0149] In one example, the data source includes both graph databases and other data sources. Corresponding to Table 1 in Example 1, the data source mapping for the standard names of data objects supports multiple types (graph databases, relational databases, search engines, etc.). The same user query can be mapped to the schemas of different data sources simultaneously, providing a foundation for cross-data source federated queries and enabling the integration of multiple data sources.

[0150] As can be seen from the above embodiments, the query language generation method provided in this application obtains data query requirements expressed in natural language, with data sources including those other than graph databases; obtains the encoded name of the target data object type whose semantic name matches the query keywords based on the semantic name and encoded name of the data object type; and generates a query statement corresponding to the query requirements through a large language model based on the encoded name of the target data object type and the query requirements. This processing method allows the large language model to convert natural language into query language based on the data object type (schema subset) matching the query requirements, avoiding the large language model generating query language based on the complete schema. This significantly reduces the solution space of the large language model and reduces the attention distraction caused by schema information overload, thus effectively improving the accuracy of natural language to query language conversion.

[0151] Fourth embodiment In the above embodiments, a query language generation method is provided. Correspondingly, this application also provides a query language generation apparatus. This apparatus corresponds to the embodiments of the method described above. Since the apparatus embodiments are basically similar to the method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments. The apparatus embodiments described below are merely illustrative.

[0152] This application also provides a query language generation apparatus, comprising: a query requirement acquisition unit, a terminology mapping unit, and a syntax mapping unit. The query requirement acquisition unit is specifically used to acquire data query requirements expressed in natural language, with the data source including data sources other than graph databases; the terminology mapping unit is specifically used to acquire the encoded name of the target data object type whose semantic name matches the query keywords, based on the semantic name and encoded name of the data object type; the syntax mapping unit is specifically used to generate a query statement corresponding to the query requirement using a large language model, based on the encoded name of the target data object type and the query requirement.

[0153] Fifth embodiment In the above embodiments, a query language generation method is provided. Correspondingly, this application also provides an electronic device. This device corresponds to the embodiments of the above method. Since the device embodiments are basically similar to the method embodiments, the description is relatively simple, and relevant details can be found in the description of the method embodiments. The device embodiments described below are merely illustrative.

[0154] The electronic device of this embodiment includes: a memory and a processor; the memory is used to store a program that implements the query language generation method, and the device is powered on and runs the program of the query language generation method through the processor.

[0155] Memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0156] In specific implementations, the electronic device may further include one or more of the following components: a power supply component, an input / output (I / O) interface, and a communication component. The power supply component provides power to various components of the electronic device. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device. The I / O interface provides an interface between the processor 503 and peripheral interface modules, which may be a keyboard, click wheel, buttons, etc. The communication component is configured to facilitate wired or wireless communication between the electronic device and user devices (such as smartphones, tablets, etc.).

[0157] Sixth Embodiment This application also provides a computer-readable storage medium. Since the embodiments of the computer-readable storage medium are substantially similar to the method embodiments, the description is relatively simple; relevant details can be found in the description of the method embodiments. The computer-readable storage medium embodiments described below are merely illustrative.

[0158] In this embodiment, a non-transitory computer-readable storage medium including instructions is provided, such as a memory including instructions, which can be executed by a processor of an electronic device to complete the query language generation method provided in this disclosure. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0159] It should be noted that the embodiments of this application may involve the use of user data. In practical applications, user-specific personal data may be used in the scheme described herein within the scope permitted by applicable laws and regulations, provided that it complies with the applicable laws and regulations of the country (e.g., with the user's explicit consent, with the user being properly notified, etc.).

[0160] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

[0161] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0162] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0163] 1. Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0164] 2. Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

Claims

1. A query language generation method, characterized in that, include: Obtain graph database query requirements expressed in natural language; Based on the semantic name and encoded name of the graph element type, obtain the encoded name of the target graph element type whose semantic name matches the query keywords; Based on the encoded name of the target graph element type and the query requirements, a graph query statement corresponding to the query requirements is generated using a large language model.

2. The method according to claim 1, characterized in that, The step of obtaining the encoded name of the target graph element type that matches the query keyword based on the semantic name and encoded name of the graph element type includes: Based on the semantic name and encoded name of the graph element type, obtain the encoded name of the first target graph element type whose semantic name matches the text of the query keyword.

3. The method according to claim 1, characterized in that, The step of obtaining the encoded name of the target graph element type that matches the query keyword based on the semantic name and encoded name of the graph element type also includes: Based on the semantic name and encoded name of the graph element type, obtain the encoded name of the second target graph element type whose semantic name is similar to the character-level semantics of the query keyword.

4. The method according to claim 1, characterized in that, The step of obtaining the encoded name of the target graph element type that matches the query keyword based on the semantic name and encoded name of the graph element type also includes: Based on the graph pattern, obtain the semantic names of multiple graph element types; using a large language model, based on the semantic names of multiple graph element types, obtain the encoded name of a third target graph element type whose semantic name is similar to the query keyword from the multiple graph element types.

5. The method according to any one of claims 2 to 4, characterized in that, The step of obtaining the encoded name of the target graph element type that matches the query keyword based on the semantic name and encoded name of the graph element type also includes: If the query keyword has multiple meanings, then according to the query requirements, the encoding name of the target graph element type that matches the query keyword is selected from the multiple candidate graph element type encoding names with different meanings corresponding to the query keyword.

6. The method according to claim 5, characterized in that, The step of selecting the encoding name of the target graph element type that matches the query keyword from multiple candidate graph element type encoding names with different meanings corresponding to the query keyword, based on the query requirement, includes: Obtain a list of positive enhancing keywords and / or a list of negative excluding keywords for candidate graph element types; If the query request includes keywords from the positive reinforcement keyword list, then increase the confidence of the candidate graph element type; If the query request includes keywords from the negative boosting keyword list, then reduce the confidence of the candidate graph element type; Based on the adjusted confidence of the candidate graph element types, select the encoding name of the target graph element type that matches the query keywords from multiple candidate graph element type encoding names with different meanings.

7. The method according to claim 1, characterized in that, Also includes: Obtain historical query requests similar to the stated query request; The step of generating a graph query statement corresponding to the query requirement using a large language model based on the encoded name of the target graph element type and the query requirement includes: Based on the encoded name of the target graph element type, the query requirement, and the graph query statements of similar historical query requirements, a graph query statement corresponding to the query requirement is generated through a large language model.

8. A method for converting natural language to query language, characterized in that, include: Obtain data query requirements expressed in natural language, with data sources including those other than graph databases; Based on the semantic name and encoded name of the data object type, obtain the encoded name of the target data object type whose semantic name matches the query keywords; Based on the encoded name of the target data object type and the query requirements, a query statement corresponding to the query requirements is generated using a large language model.

9. A query language generation device, characterized in that, include: The query requirement acquisition unit is used to acquire graph database query requirements expressed in natural language. The terminology mapping unit is used to obtain the target graph element type whose semantic name matches the query keyword, based on the semantic name of the graph element type. The syntax mapping unit is used to generate a graph query statement corresponding to the query requirement through a large language model, based on the encoded name of the target graph element type and the query requirement.

10. An electronic device, characterized in that, include: processor; as well as A memory for storing a program for implementing the method according to any one of claims 1 to 8, wherein the device is powered on and the program for running the method is executed by the processor.

Images