Graph-based data query method, device, medium, product

Abstract

This application relates to the field of computer technology, and particularly to a graph-based data query method, device, medium, and product. The method includes: acquiring stored graph data, which represents the business data of various business objects within an enterprise and the relationships between these objects; responding to a user's dialogue message as a business query, analyzing and processing the message to obtain query analysis results, including the target business object and its corresponding data query conditions; acquiring the user's data query permission information and generating a query instruction based on the query analysis results and permission information; querying the target business object's business data in the graph data according to the query instruction to obtain query results; and generating a feedback message based on the query results and returning it to the user. This method solves the problem of low efficiency in traditional query methods.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a data query method, device, medium, and product based on graphs. Background Technology

[0002] In enterprise business scenarios, staff often need to query various business data to support business decisions. These queries often involve multiple related business objects, requiring the writing of structured query statements to complete the retrieval in the enterprise knowledge database.

[0003] In practice, business personnel need to clarify the target and scope of data queries with technical personnel, and then the technical personnel will write the corresponding query statements according to specific business needs, and finally execute the retrieval operation.

[0004] The above-mentioned model is not only time-consuming and labor-intensive, but also requires repeated communication and adjustment of query statements when facing changing business needs, resulting in low overall data retrieval efficiency. Summary of the Invention

[0005] This application provides a graph-based data query method, device, medium, and product that can achieve accurate data query with natural language input, complete access control of business data, and solve the problem of low efficiency in traditional query modes.

[0006] In a first aspect, embodiments of this application provide a data query method based on a graph, the method comprising: Retrieve stored graph data, which is used to represent the business data of various business objects of an enterprise and the relationships between these business objects; When the dialogue message from the user object is a business query type, the dialogue message is analyzed and processed to obtain the query analysis results, which include the target business object and its corresponding data query conditions. Obtain the user's data query permission information, and generate query instructions based on the query analysis results and the data query permission information; Based on the query command, query the business data of the target business object in the graph data to obtain the query results; The system generates a feedback message for the dialogue based on the query results and returns it to the user object.

[0007] The first benefit is as follows: By acquiring graph data containing various business objects and their relationships, a structured foundation is provided for the organization and querying of complex business data. Upon receiving a dialogue message, the message type is first determined, and subsequent processes are triggered only when the message type is a query, avoiding the ineffective use of system resources by non-query intentions. By deconstructing and analyzing the dialogue message, clear target business objects and their data query conditions are obtained, transforming the fuzzy expressions of natural language into structured query tasks, laying the foundation for accurately understanding the user's intent. When generating query instructions, the query analysis results and the user's data query permission information are combined to ensure that the final executed query instruction not only conforms to the user's query intent but is also strictly limited to the user's authorized data scope. Based on this query instruction, the data of the target business object is queried in the graph data, the query results are obtained, and a feedback message is generated and returned to the user, realizing a complete closed loop from natural language input to accurate data output.

[0008] In one implementation, the dialogue message responding to the user object is a business query type. The dialogue message is analyzed and processed to obtain query analysis results, including: Retrieve the user object's historical dialogue messages, which are received sequentially from the dialogue messages. Reconstructing the dialogue messages based on historical dialogue messages yields reconstructed messages, which have the same meaning as the original dialogue messages. The reconstructed message is disassembled and analyzed to obtain the query analysis results.

[0009] In this implementation, when analyzing user messages, historical dialogue messages received in the same order as the user message are reconstructed to obtain reconstructed messages with the same meaning but clearer expression. These reconstructed messages are then further analyzed. This design effectively handles omissions and references in multi-turn dialogues, ensuring that the decomposition results accurately reflect the user's complete query intent and improving semantic understanding capabilities in multi-turn dialogue scenarios.

[0010] In one implementation, data query permission information of the user object is obtained, and a query instruction is generated based on the query analysis results and the data query permission information, including: Generate a query script based on the query analysis results. The query script is used to guide the generation of query instructions. The query script includes query keywords corresponding to the target business object and data query conditions. Retrieve the stored scalar dictionary, which contains scalar strings corresponding to various business objects; Execute the query script, perform semantic analysis on the query keywords and scalar strings in the scalar dictionary, and generate a query statement that matches the query keywords; The query command is generated by combining the query statement and data query permission information.

[0011] In this implementation, a scalar dictionary is mapped to precise scalar values ​​stored in the database, which solves the semantic matching problem between the ambiguity of natural language expression and the precise matching requirements of the database, thus achieving precise query while ensuring semantic understanding.

[0012] In one implementation, a query script is executed to perform semantic analysis on the query keywords and scalar strings in the scalar dictionary, generating a query statement that matches the query keywords, including: Obtain the vector library corresponding to the scalar dictionary. The vector library includes multiple feature vectors obtained by extracting features from the scalar strings corresponding to various business objects. The i-th scalar string in the scalar dictionary corresponds to the i-th feature vector in the vector library, where i is a positive integer. Extract features from the query keywords to obtain the query feature vector; Calculate the matching degree between the query feature vector and multiple feature vectors; Based on the scalar string corresponding to at least one feature vector whose matching degree meets the preset matching requirements, a query statement matching the query keyword is generated.

[0013] In this implementation, a vector library is used to perform matching analysis between query keywords and scalar strings. Feature vectors are extracted from the query keywords and compared with pre-stored scalar string feature vectors in the vector library. The matching degree is calculated, and a query statement is generated based on the scalar strings corresponding to feature vectors that meet the matching degree requirements. This semantic matching method, based on vector similarity, effectively identifies scalar values ​​that are semantically similar to but not entirely consistent with the user's input, improving the accuracy and recall of semantic understanding and ensuring that even colloquial expressions input by users can be correctly understood. Through the collaboration of vector retrieval and a scalar dictionary, the fuzzy semantics of user input are effectively mapped to precise scalar values ​​recognizable by the database, achieving a robust conversion from natural language to precise queries.

[0014] In one implementation, the method further includes: If an error is detected during the execution of the query script, the error information is obtained, which indicates the cause of the error. The query script is updated based on the anomaly information to obtain the updated query script; Execute the updated query script.

[0015] This implementation method automatically corrects script execution failures without manual intervention, significantly improving system robustness and automation. Exception information covers various types, including syntax errors, null object access, permission exceptions, and type errors, providing a basis for accurately locating the cause of the problem and enabling the system to make targeted corrections, thus increasing the success rate of corrections.

[0016] In one implementation, the query script is updated based on the exception information to obtain an updated query script, including: Retrieve update records, which include the cumulative number of times the query script has been updated and the historical update methods for each update; If the cumulative number of times is less than or equal to the preset number of times threshold, the query script is updated using the first update method to obtain the updated query script. The first update method is different from the historical update method.

[0017] This implementation avoids repeated failures of the same correction strategy by dynamically adjusting the update method, thus improving the success rate in scenarios with multiple corrections. Combined with a preset threshold for the number of corrections, it avoids the consumption of system resources by infinitely looping corrections, ensuring both correction effectiveness and processing efficiency.

[0018] In one implementation, the method further includes: If the message type of the dialogue message is dialogue, generate the reply content based on the dialogue message; Return the response to the user.

[0019] In this implementation, when the message type is conversational, the response content is directly generated based on the user message and returned to the user. This design distinguishes between casual chat requests and data query requests, responding directly to non-query-intentioned requests to avoid triggering subsequent data query processes, saving system resources. At the same time, timely responses improve the user experience and give the system a more natural interactive capability.

[0020] Secondly, embodiments of this application provide a graph-based data query device, including: The data acquisition module is used to acquire stored graph data, which is used to represent the business data of various business objects of the enterprise and the relationships between these business objects. The processing module is used to respond to the user object's dialogue message as a business query type, analyze and process the dialogue message, and obtain the query analysis results, which include the target business object and its corresponding data query conditions. The data acquisition module is also used to acquire data query permission information of user objects, and generate query instructions based on query analysis results and data query permission information; The processing module is also used to query the business data of the target business object in the graph data according to the query command and obtain the query results; The processing module is also used to generate feedback messages for the dialogue messages based on the query results and return them to the user object.

[0021] Thirdly, this application also provides an electronic device. The electronic device includes a memory, one or more processors, and a computer program stored in the memory and executable on the processor. The electronic device executes the computer program to implement any of the implementations of the first aspect described above.

[0022] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method of any of the implementations of the first aspect described above.

[0023] Fifthly, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to execute any of the implementation methods of the first aspect described above.

[0024] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the architecture of a graph-based data query system provided in one embodiment of this application; Figure 2 This is an interactive flowchart of a graph-based data query system provided in an embodiment of this application; Figure 3 This is a flowchart of a graph-based data query method provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the process of acquiring spectral data according to an embodiment of this application; Figure 5 This is a structural block diagram of a graph-based data query device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] In modern enterprise management, employees need to frequently query various business data to support business decisions. Enterprise business data is often associated with multiple business objects. The relevant data of various business objects and the relationships between them constitute the core business data system of the enterprise. Queries on this type of data need to be completed in the data storage carrier based on standardized query commands.

[0028] Most enterprise personnel typically lack the ability to directly generate standardized query commands. They need to first clarify the target business object and specific query requirements with technical personnel, who then write the corresponding query commands and execute the data retrieval based on these requirements. Furthermore, when business needs change, it is necessary to communicate again and adjust the query commands. This not only makes the overall operation process cumbersome, time-consuming, and labor-intensive, but also leads to low overall efficiency in data querying due to repeated communication, making it difficult to match the enterprise's need for efficient business decision-making.

[0029] To address the shortcomings of the aforementioned technologies, this application proposes a graph-based data query method to enable enterprise-level natural language queries of entity data. This method can efficiently and accurately retrieve enterprise business data using natural language, meeting the data query needs of enterprise personnel when handling actual business operations.

[0030] In the preparation phase, this method first performs graph-based processing on the enterprise domain entity model and entity data to construct a graph data system. This system includes data on various business objects of the enterprise and the relationships between them. Simultaneously, a scalar dictionary and a vector library are built during the construction of this graph data system. The scalar dictionary pre-generates and stores scalar strings corresponding to various business objects of the enterprise. These scalar strings are character sets formed after standardizing and structuring information such as attribute fields, names, and business definitions of each business object, which can be used for natural language semantic matching. The vector library is a set of feature vectors obtained by extracting features from each scalar string in the scalar dictionary (e.g., text vectorization based on a pre-trained language model). The i-th scalar string in the scalar dictionary corresponds to the i-th feature vector in the vector library (i is a positive integer).

[0031] Based on this, this method integrates natural language retrieval capabilities with graph traversal query engines, vector storage, and large model technology. By constructing a closed loop of query agent, it achieves fully automated processing from user object natural language message input to final natural language feedback. The specific steps are as follows.

[0032] First, the system receives a dialogue message containing text content from a user and determines the message type. If the message type is a query, the system parses and decomposes the dialogue message to obtain query analysis results. These results include the target business object and its corresponding data query conditions. Then, an executable query script is dynamically generated based on the query analysis results. This query script uses a graph traversal programming paradigm, with a syntax structure based on a general scripting language. It includes built-in application programming interfaces for multi-step graph traversal and relational retrieval, and its execution environment is bound to the current graph database, enabling direct traversal operations at the entity and relation levels. The query script is then executed. First, features are extracted from the query keywords to obtain query feature vectors. The matching degree between these query feature vectors and multiple feature vectors in the vector library is calculated. The scalar string corresponding to at least one feature vector whose matching degree meets the preset matching requirements is determined as the target string. Semantic analysis of the query keywords and the scalar dictionary is completed. A query statement matching the query keywords is generated based on the target string. Simultaneously, the system obtains the user's data query permission information and combines the query statement and data query permission information to generate a standardized query instruction.

[0033] If an execution error is detected during the execution of the query script, the script will be automatically updated and re-executed based on the error information until the query results for the target business object are obtained. Finally, a natural language feedback message that matches the corresponding expression style will be generated and returned to the user object by combining the dialogue context information. If it is a dialogue type message, a reply content will be generated directly.

[0034] This method can construct a knowledge graph to decompose and identify the business entities involved in the natural language messages of user objects, achieve high-accuracy data query under natural language input, complete fine-grained business data access control, and flexibly meet the real-time query and data processing needs of user objects by dynamically generating query scripts. Relying on the script automatic repair mechanism, it can greatly improve the robustness and actual availability of the system, and completely solve the problems of low efficiency of traditional query mode and the integration and adaptability defects of related technical solutions.

[0035] Figure 1 This is a schematic diagram of the architecture of an entity data graph storage and query engine provided in an exemplary embodiment of this application. The architecture 100 is used to implement the graph-based data query method provided in this application, and the architecture can be deployed in a terminal / server.

[0036] like Figure 1 As shown, the architecture 100 includes a data query agent layer 110, a data retrieval execution layer 120, and a graph data storage layer 130.

[0037] The data query agent layer 110 is used to interact with user objects and understand their intentions. It includes a multi-turn dialogue module, a question redefinition module, a task decomposition module, and a query script generation module. Specifically, the multi-turn dialogue module receives natural language messages input by the user object and manages the dialogue context; the question redefinition module reconstructs the dialogue messages based on historical dialogues to obtain a clear task sequence; the task decomposition module breaks down the reconstructed task sequence into target business objects and their corresponding data query conditions; and the query script generation module generates an executable query script based on the decomposition results.

[0038] The data retrieval execution layer 120 is used to execute query scripts and return query results. It includes an execution engine module, an API query generation module, a data permission filtering module, and a semantic retrieval and scalar filtering module. Specifically, the execution engine module runs the query scripts; the API query generation module converts API calls in the query scripts into underlying data query statements, such as converting them into SQL (Structured Query Language) statements; the data permission filtering module injects user object data permission information when generating the underlying data query statements; and the semantic retrieval and scalar filtering module performs semantic matching processing on the semantic conditions in the query scripts, converting fuzzy query conditions into precise scalar values.

[0039] The graph data storage layer 130 is used to store business data and its indexes, including graph data, a scalar dictionary, and a vector library. The graph data stores data on various business objects of the enterprise and their relationships in the form of entity vertices and relation edges; the scalar dictionary stores string fields extracted from the business data that require semantic retrieval; and the vector library stores vector representations obtained by vectorizing the strings in the scalar dictionary.

[0040] Based on the above architecture, the data query process of this application is as follows: First, the data query agent layer 110 receives the dialogue message, manages the context through the multi-turn dialogue module, and after reconstruction by the question redefinition module, the query analysis result is obtained by the task decomposition module, and then the query script generation module generates the query script; then, the execution engine module of the data retrieval execution layer 120 runs the query script, converts the fuzzy query conditions in the script into precise scalar values ​​through the semantic retrieval and scalar filtering module, converts the script into low-level query statements through the API query generation module, and after the data permission filtering module injects the user object's permission information, the query result is obtained from the graph data storage layer 130; finally, the query result is returned to the user object.

[0041] Figure 2This is an interactive flowchart of a graph-based data query system provided in an exemplary embodiment of this application. The system includes a data query agent 210 (i.e., Figure 1 The data query agent layer 110, large language model 220, and script execution engine 230 shown are also included. Figure 1 The system includes the execution engine module shown in the diagram and the graph data 240. It interacts with the user terminal 200 to achieve a complete data query and feedback process, including the following steps.

[0042] S2001, the user sends a natural language query message to the data query agent.

[0043] For example, a user enters everyday language, such as "order amount and product details of store A in the last 5 days" as a natural language query message, and the system begins to process the user's query request.

[0044] S2002, the data query agent obtains historical dialogue messages and sends the historical dialogue messages and natural language query messages to the large language model.

[0045] The data query agent retrieves previous communication records with the user from the dialogue context and submits them, along with the current question, to the large language model, making it easier for the model to understand the complete dialogue context.

[0046] S2003, the large language model redefines the natural language query message based on historical dialogue messages to obtain the reconstructed message, and decomposes the reconstructed message into tasks to obtain query analysis results, which include the target business object and its corresponding data query conditions.

[0047] The large language model first determines whether the user's question is casual conversation or a genuine query. If it is a query, it combines historical dialogues to complete the current question into a complete query statement (e.g., rewriting "What about 7-Eleven?" as "The number of orders at 7-Eleven on Jiefang Road"). Then, it breaks down the complete question into specific data query tasks, such as the entities to be queried, such as stores, orders, and products, as well as their corresponding attributes and conditions.

[0048] S2004 returns the query analysis results to the data query agent.

[0049] The agent obtains a structured task description, including information such as the type of business object to be queried, filtering conditions, and time range, in preparation for generating a query script.

[0050] S2005, the data query agent sends the query analysis results to the large language model, instructing the large language model to generate a query script based on the query analysis results.

[0051] The agent submits the decomposed task information back to the large language model, instructing it to generate query scripts that can be executed in the graph data based on this task information.

[0052] S2006, the large language model generates a query script based on the query analysis results and returns the query script to the data query agent.

[0053] Based on the task description and the preset graph data model, the large language model generates a query script that meets the preset format requirements. This script contains the query conditions and traversal path for the target business object.

[0054] The preset format requirements refer to the query and manipulation scripting language specifications designed for entity graphs. This specification defines a scripting language based on a general scripting language syntax and a natively integrated graph traversal application interface, used to describe how to perform multi-step traversal, conditional filtering, and association retrieval in graph data.

[0055] Optionally, in one implementation, the query script is written in JavaScript syntax style and expresses the graph traversal logic through chained calls. Its preset format requirements include: based on JavaScript syntax, native integrated graph traversal application interface, support for chained calls to express traversal paths, and execution context bound to the current graph database.

[0056] S2007, the data query agent sends the query script to the script execution engine.

[0057] The agent then submits the generated query script to the execution engine for execution, thus initiating the actual data retrieval phase.

[0058] S2008, the script execution engine executes the query script to initiate a data query to the map data.

[0059] When the execution engine runs the script, it identifies the string-type query conditions (such as the store name equals "Store A"), converts the fuzzy words entered by the user object into precise values ​​in the database (such as "Store A - Shanghai Waigaoqiao Store") through a scalar dictionary and vector library, and obtains the current user object's permission information. When translating the script into the underlying database statement (such as an SQL statement), it forcibly injects permission filtering conditions to ensure that the query results are within the user object's permission range.

[0060] S2009: If the query result is not empty, the map data returns the query result to the script execution engine.

[0061] The system retrieves data from the graph data based on the query statement submitted by the execution engine, and returns the business data that meets the conditions to the execution engine in JSON format.

[0062] S2010, the script execution engine returns the query results to the data query agent.

[0063] The execution engine passes the retrieved data to the agent for further processing.

[0064] S2011, the data query agent sends the query results to the large language model, instructing the large language model to generate a feedback message.

[0065] The agent submits the raw data to the large language model again, requesting it to transform the structured data into a natural language representation that is easy for the user to understand.

[0066] S2012, the large language model generates a feedback message in natural language form based on the query results and returns the feedback message to the user.

[0067] The large language model generates answers that conform to everyday language habits based on the query results and the natural language query messages sent by the user, such as "Store A has had 3 orders in the past 5 days, with a total amount of 5200 yuan, including products such as shampoo, conditioner, and face masks", which are directly presented to the user.

[0068] S2013, if the query script fails to execute, the script execution engine returns an exception message to the data query agent.

[0069] When a syntax error, empty query result, or insufficient permissions occur during script execution, the execution engine captures the exception information and passes it to the agent.

[0070] In S2014, the data query agent sends the abnormal information and the currently executed query script to the large language model, instructing the large language model to correct and update the query script.

[0071] The agent submits the error information along with the previously generated query script to the large language model, requesting it to analyze the cause of the error and provide a correction plan.

[0072] In S2015, the large language model generates a corrected query script based on the anomaly information and returns the corrected query script to the data query agent.

[0073] The large language model adjusts and corrects the original script based on the error type and context information, generating a new executable script.

[0074] The data query agent sends the revised query script to the script execution engine and executes S2007 to S2012 in a loop. When the execution is successful or the preset number of retries is reached, the loop exits.

[0075] The agent will then pass the revised script back to the execution engine to run, repeating the process of data retrieval and result return. If multiple attempts still fail, it will stop retrying and return an error message.

[0076] Figure 3 This is a flowchart of a graph-based data query method provided in an exemplary embodiment of this application. This method can be deployed by, for example... Figure 1 The method, executed by the terminal or server of the system shown, includes the following steps.

[0077] S301, retrieve the stored map data.

[0078] Graph data is used to characterize the business data of various business objects within an enterprise, as well as the relationships between these business objects.

[0079] In enterprise business scenarios, there are typically multiple business objects and the relationships between them. Taking a retail enterprise as an example, business objects include stores, sales orders, and products. There is a sales relationship between stores and sales orders, and an inclusion relationship between sales orders and products. These business objects and their relationships constitute the core data of an enterprise's daily operations.

[0080] Graph data refers to the organization and presentation of the aforementioned business data in the form of entity vertices and relational edges. Each business object instance is an entity vertex, for example, "Store A - Shanghai Waigaoqiao Store" is a vertex of the store type, and "Order 123" is a vertex of the sales order type; the relationships between business objects are represented by relational edges, for example, a relational edge is established between the store vertex and the order vertex (e.g., the "ownership" relationship between the store and the order, meaning that the store owns the order), and a relational edge is established between the order vertex and the product vertex (e.g., the "containment" relationship between the order and the product, meaning that the order contains a certain product).

[0081] Each entity vertex and relation edge can be appended with attribute information. For example, a store vertex can include attributes such as store name and address, while an order vertex can include attributes such as order date and total amount. Through this node-edge-attribute data organization, graph data can intuitively and efficiently represent the full picture of enterprise business data and its inherent relationships.

[0082] Figure 4 This is a schematic diagram of the process of acquiring spectral data, as follows.

[0083] First, obtain the enterprise domain entity model 410 and its corresponding form data 420.

[0084] Enterprise Domain Entity Model 410 is a structured definition of the types, attributes, and relationships between entities involved in business activities. For example, a store entity is defined to include attributes such as store name and address, and a sales order entity is defined to include attributes such as order date and total amount. The "ownership" relationship between stores and sales orders and the "inclusion" relationship between sales orders and products are also defined.

[0085] Form data 420 contains the specific records generated by these entities in actual business operations, such as specific store information and detailed data for each order. Form data 420 is the actual content populated according to the organization method of the enterprise domain entity model 410.

[0086] The enterprise domain entity model 410 is mapped to a graph ontology model. The graph ontology model is a technical implementation definition of the entity model under the graph database technology paradigm. It transforms business concepts into elements that the graph database can recognize. For example, it clarifies the vertex label corresponding to each entity type in the graph (such as "Shop / store (representing the store entity in the business object)" and "SalesOrder / sales order (representing the order entity in the business object)"). It clarifies the edge type corresponding to each relationship (such as "hasOrder / owns order (representing the association between the store vertex and the order vertex, i.e., the store owns the order)" and "contains / contains (representing the association between the order vertex and the product vertex, i.e., the order contains a certain product)"). It also defines the attribute fields that can be attached to vertices and edges and their data types.

[0087] Based on the mapped graph ontology model, the form data 420 is graph-based, transforming it into actual graph data. Following the definition of the graph ontology model, the graph-based processing converts each record in the form data 420 into a corresponding entity vertex, the relationships between records into relational edges, and attribute values ​​into the attributes of the vertices and edges. For example, store records are converted into vertices labeled "Shop," order records are converted into vertices labeled "SalesOrder," and a relational edge of type "hasOrder" is established between the store vertex and the order vertex.

[0088] In some embodiments, while converting form data 420 into graph data, all string fields that need semantic retrieval, such as store name and product name, are extracted from the form data to construct a scalar dictionary.

[0089] Each record in the scalar dictionary contains a scalar string and its corresponding business object identifier. Each scalar string in the scalar dictionary is vectorized to obtain the corresponding feature vector, and the feature vector is associated with the scalar string and stored to form a vector library (i.e., vectorized storage).

[0090] Through the aforementioned graph construction process, graph data containing entity vertices, relation edges, and attributes, along with a corresponding scalar dictionary and vector library, are obtained for subsequent natural language-based data queries. By employing a two-layer design of scalar dictionary and vector storage, string attributes that may serve as natural language filtering targets are uniformly extracted and stored in the scalar dictionary table, while simultaneously undergoing vectorization to form a vector index. This achieves a workflow from "semantic candidate scalar retrieval to precise scalar filtering," enabling the graph traversal engine to collaboratively call the scalar dictionary and vector library, thus breaking down the barrier between fuzzy semantic input and precise graph queries. This solves the problem of the lack of native integration between graph data and semantic retrieval in related technologies.

[0091] This graph-based construction process achieves an integrated transformation from domain entity models to graph data. Based on predefined entity model definitions (including entity types, attributes, and relationships), it automatically creates a graph ontology model and generates corresponding entity vertices and relationship edges, while establishing a mapping relationship between attribute fields and vertices / edges. During this process, a scalar dictionary for natural language retrieval is maintained concurrently, recording the reverse mapping relationship between each scalar string and its corresponding vertex or edge, facilitating rapid data source location during subsequent retrievals. Furthermore, this construction process supports batch data acquisition and transactional commit mechanisms, enabling efficient processing of graph-based transformations of large-scale business data and meeting the data storage needs of enterprise-level high-concurrency scenarios.

[0092] Furthermore, a two-layer design combining a scalar dictionary and vector storage is introduced. When constructing the scalar dictionary, all string attributes that might be targets for natural language filtering (such as store names, product names, addresses, etc.) are extracted and stored in the scalar dictionary table. Each string in the scalar dictionary table is vectorized, generating a corresponding feature vector which is then stored in a vector library, forming a vector index associated with the scalar dictionary. This enables a workflow of "semantic candidate scalar retrieval → precise scalar filtering": when a user inputs query conditions containing fuzzy semantics, the system first finds the semantically closest scalar candidate value through vector retrieval, and then uses these precise scalar values ​​for accurate matching in the graph data. This design effectively maps the fuzzy expressions of natural language to precise scalar values ​​that the database can recognize, fundamentally resolving the contradiction between semantic understanding and precise querying, laying the foundation for the accuracy of subsequent query steps.

[0093] S302, in response to the user object's dialogue message being of the business query type, the user dialogue message is decomposed and analyzed to obtain the decomposed query analysis results.

[0094] Optionally, receive the dialogue message and determine the message type of the dialogue message.

[0095] The dialogue message contains text content, which is everyday language entered by the user in natural language to express the user's intentions or needs, such as asking for data, initiating small talk, or making other interactive requests.

[0096] Message types for dialogue messages include, but are not limited to, dialogue-type and query-type messages. Dialogue-type messages are typically used in everyday communication scenarios, such as users entering greetings or social phrases like "hello" or "thank you," without involving specific data query needs. Query-type messages, on the other hand, are used in data retrieval scenarios, such as users entering "store A's order amount for the last 5 days" or "last month's sales ranking," expressing the user's need to obtain specific business data from the system.

[0097] Optionally, different types of messages correspond to different processing methods: (1) For dialogue-type messages, the system can directly generate corresponding social responses to enhance the interactive experience; (2) For query-type messages, it is necessary to further analyze the user's intent and execute the data retrieval process.

[0098] For example, when the message type is a dialogue, a response is generated based on the dialogue message and returned to the user object. In this case, steps S303-S306 are not executed.

[0099] For example, if a user enters "Hello," the data query agent recognizes the message as a conversational type. Without executing a data query process, it can directly generate a greeting such as "Hello, how can I help you?" to respond to the user's social interaction needs and improve the user experience. This approach distinguishes between casual conversation requests and data query requests, avoiding unnecessary subsequent processing for non-query-intent requests and saving system resources.

[0100] When the message type is a business query, the dialogue message is analyzed and processed to obtain the query analysis results.

[0101] The query analysis results are structured information obtained by deconstructing and analyzing the natural language queries of user objects. This information is used to clarify the goals and constraints for generating subsequent query scripts. The query analysis results include the target business object and its corresponding data query conditions.

[0102] The target business object refers to the core business entity type involved in the user's query intent, that is, the business object that the user wants to query. For example, in a retail scenario, the target business object could be a store, a sales order, or a product.

[0103] Data query conditions refer to the specific operations and conditions that need to be performed for the target business object, that is, what information the user object wants to query about the object and how to query that information. Data query conditions include at least one of the following: (1) Filtering conditions: constraints on the attributes of the business object, such as time range, name matching, etc.; (2) Query attributes: fields that need to be returned, such as order amount, product name, etc.; (3) Aggregation method: whether statistical calculation is required, such as counting, summation, average, etc.; (4) Association relationship: whether it is necessary to obtain information of other related business objects, such as the product details corresponding to the order.

[0104] In some embodiments, to ensure the accuracy of semantic understanding, the user object's dialogue messages can be analyzed and processed in conjunction with historical dialogue messages.

[0105] Optionally, retrieve the user's historical dialogue messages, which are received sequentially with the initial dialogue messages. Reconstruct the dialogue messages based on the historical messages to obtain reconstructed messages, which have the same meaning as the initial dialogue messages. Analyze the reconstructed messages to obtain query analysis results.

[0106] For example, if a user previously asked "the number of orders at store A on Jiefang Road," and this time only asks "what about 7-Eleven?", then by combining the historical dialogue, the message for this round can be reconstructed as "the number of orders at 7-Eleven on Jiefang Road." If it is the first dialogue, i.e. there are no historical dialogue messages, then the current dialogue message is directly disassembled and analyzed.

[0107] Deconstructing and analyzing dialogue messages (or reconstructed messages) can be achieved through a large language model or pre-defined rules. The deconstruction process transforms the user's intent expressed in natural language into a structured query task, clarifying information such as the type of business object to be queried, attribute fields, filtering conditions, aggregation methods, and time range.

[0108] For example, taking the user object query "What is the number of orders and sales amount in October? List detailed orders" as an example, after decomposition and analysis, we can obtain the following: 1. Target business object: Sales Order; 2. Data query conditions include: (1) Filtering conditions: Business date (bizDate) is between October 1, 2025 and October 31, 2025; (2) Query attributes: It is necessary to return the complete information of each order that meets the conditions, including order number, business date, total amount, associated store information, etc.; (3) Aggregation method: Order quantity (counting orders), total sales amount (summing order amounts); (4) Relationship: It is necessary to obtain the related data such as product details contained in the order.

[0109] Through the above decomposition and analysis, the vague natural language query of the user object "What is the number of orders and sales amount in October, and list the detailed orders" is transformed into a clear structured query task, laying the foundation for the subsequent generation of an executable query script.

[0110] S303: Obtain the data query permission information of the user object, and generate a query instruction based on the query analysis results and the data query permission information.

[0111] Data query permission information refers to the range of data that a user is authorized to access within the system. It is used to constrain the results during the query process, ensuring that a user can only access the data they are authorized to view. This permission information typically manifests as a set of accessible business object identifiers (such as a list of store IDs), data range conditions (such as region or department), or access rules based on roles / positions.

[0112] The methods for obtaining data query permission information include, but are not limited to, the following: (1) User object identity acquisition: Based on the unique identifier of the currently logged-in user object (such as user object ID, employee number), query the data access scope authorized to the user object from the permission management system or database. For example, if the permission record of user object Zhang San shows that he can access all stores in region A, then the permission information is that the store belongs to region A.

[0113] (2) Role-based or position-based access: Obtain the preset permission template for the role or position to which the user belongs. For example, the regional manager role has the default permission to view the data of stores in the region under its jurisdiction, so the permission information is the list of regions that can be viewed.

[0114] (3) Dynamic acquisition based on context: In some scenarios, permission information can be dynamically generated based on the current operation context of the user object. For example, if the user object can only view the orders it created, then the permission information is that the order creator is equal to the current user object.

[0115] (4) Retrieval based on cache: To improve efficiency, user object permission information is loaded into the cache when logging in, and the query is read directly from the cache to avoid frequent access to the database.

[0116] After obtaining data query permission information, it is combined with the query analysis results (including the target business object and data query conditions) to generate the final query instruction. This process incorporates permission conditions as mandatory constraints into the query statement. For example, if the query analysis results require querying orders for store "Store A", but the current user object can only access stores in the South China region, the generated query instruction will simultaneously include the store name condition "Store A" and the store region condition "South China region", ensuring that the query results both satisfy the user object's intent and are within the scope of permissions.

[0117] Optionally, a query script can be generated based on the query analysis results. The query script is used to guide the generation of query instructions and includes query keywords corresponding to the target business object and data query conditions.

[0118] The query script is written using a predefined graph query language specification. It's a dedicated scripting language based on JavaScript syntax and natively integrated with the graph traversal API. It describes how to perform multi-step traversal, conditional filtering, and relational retrieval within graph data. By transforming the user's natural language intent into structured query analysis results and then dynamically generating executable query scripts, it achieves precise conversion from natural language to executable query instructions. The query script contains query keywords corresponding to the target business object and data query conditions, such as the target business object's tag name (e.g., "SalesOrder"), attribute field names (e.g., "bizDate"), and specific condition values ​​entered by the user (e.g., "Store A" or the date range "2025-10-01").

[0119] The query command is a low-level data query statement generated by translating the query script, and its format matches the database type used for the map data.

[0120] When the graph data is implemented based on a relational database, the query command can be an SQL statement; when the graph data is implemented based on a graph database, the query command can be a graph query language such as Cypher (a declarative graph query language used by graph databases) or Gremlin (a functional graph traversal language for graph computing frameworks).

[0121] The execution engine is responsible for running the query script, translating the script into query instructions step by step during the process, injecting user object permission filtering conditions during the translation stage, and finally executing the query instructions to obtain data from the graph data.

[0122] For example, before executing the query script, a stored scalar dictionary is retrieved, which includes scalar strings corresponding to various business objects. Then, the query script is executed, performing semantic analysis on the query keywords and the scalar strings in the scalar dictionary to generate a query statement matching the query keywords. This query statement is then combined with data query permission information to generate a query instruction.

[0123] For example, taking a user query for "orders from Store A in the last 5 days" as an example, the scalar dictionary pre-stores all store names, including "Store A - Shanghai Waigaoqiao Store", "Store A - Nanjing Road Store", "Store A - Guangzhou Beijing Road Store", "Store B - Nanjing West Road Store", etc., with each store name corresponding to a unique business object identifier. When the execution engine runs the query script, it recognizes the query keyword "Store A" and needs to match and analyze it with the store names in the scalar dictionary.

[0124] During the translation of the query script into query commands, the execution engine automatically injects permission filtering conditions based on the current user's data query permission information. For example, it adds clauses like "AND shop.id IN (list of store IDs the user has permission to access)" to the generated SQL statement. This mechanism ensures that even if the query script generated by the large language model intends to query all data, the final executed query command will be forcibly constrained within the user's authorized scope, achieving fine-grained row-level data permission control and fundamentally avoiding the risk of unauthorized access. Through this design, the system provides flexible natural language query capabilities while strictly adhering to enterprise data security standards, ensuring that users can only access the data they are authorized to view. Specifically, using data permission information as a mandatory constraint for generating query commands integrates the graph database's retrieval function with the enterprise business system's permissions, fundamentally avoiding the risk of users accessing data without authorization and ensuring enterprise data security. This solves the problem in related technologies where graph database retrieval and enterprise business systems are separated, and the search scope cannot be filtered based on user permissions.

[0125] For example, the process of semantic analysis on query keywords and scalar strings in a scalar dictionary is as follows: Obtain a vector library corresponding to the scalar dictionary. The vector library includes multiple feature vectors obtained by feature extraction of scalar strings corresponding to various business objects. The i-th scalar string in the scalar dictionary corresponds to the i-th feature vector in the vector library, where i is a positive integer. Extract features from the query keywords to obtain query feature vectors. Calculate the matching degree between the query feature vectors and multiple feature vectors. Based on the scalar string corresponding to at least one feature vector whose matching degree meets preset matching requirements, generate a query statement that matches the query keywords.

[0126] For example, continuing the example above, assuming the vector dimension is 2, the feature vectors obtained after feature extraction for each store name are as follows: "Store A - Shanghai Waigaoqiao Store" corresponds to vector V1=[0.95,0.31], "Store A - Nanjing Road Store" corresponds to vector V2=[0.92,0.28], "Store A - Guangzhou Beijing Road Store" corresponds to vector V3=[0.88,0.25], and "Store B - Nanjing West Road Store" corresponds to vector V4=[0.42,0.81]. Feature extraction is performed on the query keyword "Store A", resulting in the query feature vector Vq=[0.93,0.30]. The matching degree (e.g., cosine similarity) between Vq and V1, V2, V3, and V4 is calculated, yielding matching degrees of 0.99, 0.97, 0.94, and 0.58, respectively.

[0127] The matching degree meets the preset matching requirements, including but not limited to: (1) setting a similarity threshold and determining the feature vectors with a matching degree greater than or equal to the threshold as meeting the requirements; (2) sorting the feature vectors from high to low according to the matching degree and selecting the top K feature vectors as meeting the requirements, where K is a preset positive integer.

[0128] Taking a preset matching requirement with a similarity threshold of 0.90 as an example, the calculated matching degrees between the query feature vector Vq and each feature vector are as follows: 0.99 with V1, 0.97 with V2, 0.94 with V3, and 0.58 with V4. Comparing these matching degrees with the threshold of 0.90, the matching degrees of V1, V2, and V3 are all greater than or equal to 0.90, meeting the preset matching requirement; the matching degree of V4, 0.58, is lower than the threshold and does not meet the requirement.

[0129] Therefore, the scalar strings "Store A - Shanghai Waigaoqiao Store", "Store A - Nanjing Road Store", and "Store A - Guangzhou Beijing Road Store" corresponding to V1, V2, and V3 are determined as target strings. The execution engine uses these three target strings to generate query statements that match the query keywords, and combines them with user object permission information to generate the final query instruction. For example, the query condition can be constructed as "Store Name IN ('Store A - Shanghai Waigaoqiao Store', 'Store A - Nanjing Road Store', 'Store A - Guangzhou Beijing Road Store')".

[0130] In some embodiments, if an execution error is detected during the execution of the query script, error information is obtained, which is used to indicate the cause of the error in the query script.

[0131] Optional, exception information includes, but is not limited to: (1) syntax error (e.g., the script does not conform to the preset graph query language specification); (2) access to empty object (e.g., the traversal path does not exist, resulting in access to empty attributes), permission exception (e.g., the user object does not have permission to access a certain entity or attribute); (3) type error (e.g., string conditions are misused in numeric fields), etc.

[0132] When an exception is detected in the execution of the query script, the script execution engine captures the exception information, which indicates the specific type and cause of the exception (such as "Syntax error: missing right bracket" or "Insufficient permissions: unable to access store ID101").

[0133] The query script is updated based on the anomaly information to obtain the updated query script. The updated query script is then executed.

[0134] For example, the process of updating the query script based on error information is as follows: The error information, the original dialogue message, and the currently executing query script are used as input to construct explicit prompt words, which are then sent to the large language model, requesting it to generate an updated query script. The large language model analyzes the problem based on the error context and generates a compliant updated script, which is returned to the data query agent. The agent then submits the updated script to the execution engine for execution, forming a closed-loop process of "execution engine captures the error → feeds back to the large language model → generates the updated script → re-executes." This process can be repeated multiple times until successful execution or the preset number of retries is reached.

[0135] Optionally, retrieve the update record, which includes the cumulative number of times the query script has been updated and the historical update method for each update.

[0136] If the cumulative number of times is less than or equal to the preset number of times threshold, the query script is updated using the first update method to obtain the updated query script. The first update method is different from the historical update method.

[0137] For example, if a previous update has attempted to "fill in missing conditions" but failed, this time, methods such as "replacing the erroneous field name" or "adjusting the traversal path" can be used to improve the success rate of correction. For instance, if the first execution fails due to a syntax error (such as a missing right parenthesis), the large language model uses "syntax completion" to correct it; if the second execution fails due to accessing null objects (such as traversing to a non-existent edge), the correction uses "adding null value checks or adjusting the traversal path." By dynamically adjusting the update method, different types of errors can be handled more effectively.

[0138] The aforementioned automatic repair mechanism uses execution errors as repair input and leverages a large language model to correct the script, forming a closed-loop process. This significantly improves the success rate of query scripts in real-world execution environments, reduces manual debugging costs, and enhances the system's robustness and automation. Furthermore, by combining update records and dynamically adjusting update methods, the repair effect is further optimized, ensuring successful execution within a limited number of retries.

[0139] S304: Based on the query instruction, query the business data of the target business object in the graph data and obtain the query results.

[0140] The execution engine submits the generated query instructions to the graph data to retrieve target business object data that meets the conditions. Query results are typically returned in structured data format, containing specific information about the business object queried by the user. For example, for a query of "order amount and product details for Store A in the last 5 days," the query results might include the order number, date, total amount, and detailed information such as the product names included in each order for each matching order.

[0141] If the query result is not empty, continue with the subsequent steps to generate a feedback message. If the query result is empty, you can directly return a "No relevant data found" message, or combine it with dialogue messages for further interaction.

[0142] S305, Generate a feedback message for the dialogue message based on the query results and return it to the user object.

[0143] Optionally, the dialogue context information is determined based on the dialogue messages; the expression style of the feedback message is determined based on the dialogue context information; and a feedback message is generated based on the query results and expression style and returned to the user object.

[0144] Conversational context information refers to the type of scenario in which the user is currently asking the question, such as a routine inquiry, professional data analysis, or formal report output. This information can be determined by analyzing the wording, sentence structure, and other features of the conversation.

[0145] The correspondence between each expression style and different dialogue context information is pre-stored in a preset context correspondence table. For example: the daily inquiry context corresponds to a concise and colloquial style, and the expression style is: brief and friendly; the professional analysis context corresponds to a structured data summary style, and the expression style is: including statistical indicators and trend descriptions; the formal report context corresponds to a written and standardized style, and the expression style is: precise wording and neat format.

[0146] Based on the query results and the determined expression style, the final feedback message is generated. For example, for the same set of query results, the responses generated by different styles are as follows: (1) Routine inquiry style: briefly informs the number of orders, total amount and purchased goods; (2) Professional analysis style: while informing the basic data, supplements the analysis information such as average order amount and best-selling products; (3) Formal report style: lists the order details one by one in a standardized format, including date, amount, product details, etc. The generated feedback message is returned to the user terminal to complete the entire query process.

[0147] This approach, which adjusts feedback style based on the dialogue context, allows the system to provide responses that better suit the user's current needs by identifying the dialogue context and matching the corresponding expression style. This makes the interaction more natural and human-like. By adapting the response style to the scenario, information is delivered to the user in the most suitable form, reducing the cost for the user to process information and improving communication efficiency.

[0148] In summary, the graph-based data query method provided in this application offers a structured foundation for organizing and querying complex business data by acquiring graph data containing various business objects and their relationships. Upon receiving a dialogue message, the message type is first determined, and subsequent processes are triggered only when the message type is a query, avoiding unnecessary occupation of system resources by non-query intents. By deconstructing and analyzing the dialogue message, clear target business objects and their data query conditions are obtained, transforming the fuzzy expressions of natural language into structured query tasks, laying the foundation for accurately understanding the user's intent. When generating query instructions, the query analysis results and the user's data query permission information are combined to ensure that the final executed query instruction both conforms to the user's query intent and is strictly limited to the user's authorized data scope. Based on this query instruction, the target business object's data is queried in the graph data, the query results are obtained, and a feedback message is generated and returned to the user, realizing a complete closed loop from natural language input to accurate data output.

[0149] This solution effectively addresses the issues of inaccurate natural language query understanding, significant discrepancies between query results and the user's true intent, and a lack of data access control during the query process in related technologies. By using user permission information as a mandatory constraint for generating query commands, it fundamentally avoids the risk of users accessing data without authorization, thus ensuring enterprise data security. Furthermore, based on the multi-business object relationships within graph data, it supports complex relationship queries, meeting the query needs of enterprise users for related data and significantly improving the accuracy and usability of data queries.

[0150] Corresponding to the graph-based data query method in the above embodiments, Figure 5 The diagram shows a structural block diagram of a graph-based data query device provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0151] Reference Figure 5 The device 500 includes: The data acquisition module 510 is used to acquire stored graph data, which is used to represent the business data of various business objects of the enterprise and the relationship between various business objects. Processing module 520 is used to respond to the user object's dialogue message as a business query type, analyze and process the dialogue message, and obtain query analysis results, which include the target business object and its corresponding data query conditions. The data acquisition module 510 is also used to acquire the data query permission information of the user object, and generate query instructions based on the query analysis results and the data query permission information; The processing module 520 is also used to query the business data of the target business object in the graph data according to the query instruction, and obtain the query result; The processing module 520 is also used to generate feedback messages for the dialogue messages based on the query results and return them to the user object.

[0152] It should be noted that the information interaction and execution process between the above-mentioned devices / modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0153] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0154] To implement the above embodiments, this application also proposes an electronic device. Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0155] like Figure 6 As shown, the above-mentioned electronic device 600 includes: The system includes a memory 610 and at least one processor 620, and a bus 630 connecting the different components (including the memory 610 and the processor 620). The memory 610 stores a computer program, and when the processor 620 executes the program, it implements the robot control method of the present application embodiment.

[0156] Bus 630 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0157] Electronic device 600 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 600, including volatile and non-volatile media, removable and non-removable media.

[0158] Memory 610 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 640 and / or cache memory 650. Electronic device 600 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 660 can be used to read and write non-removable, non-volatile magnetic media (… Figure 6 Not shown; usually referred to as a "hard drive"). Although Figure 6 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 630 via one or more data media interfaces. Memory 610 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0159] A program / utility 680 having a set (at least one) of program modules 670 may be stored in, for example, memory 610. Such program modules 670 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 670 typically perform the functions and / or methods described in the embodiments of this application.

[0160] Electronic device 600 can also communicate with one or more external devices 690 (e.g., keyboard, pointing device, display 691, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 695. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 693. As shown, network adapter 693 communicates with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0161] The processor 620 executes various functional applications and data processing by running programs stored in the memory 610.

[0162] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the robot control method in the embodiments of this application, and will not be repeated here.

[0163] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0164] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0165] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / electronic device, a recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some regions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0166] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0167] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0168] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0169] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0170] In the foregoing, specific details such as particular system architectures and techniques have been set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail from obscuring the description of this application.

[0171] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0172] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0173] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0174] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0175] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0176] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A data query method based on a graph, characterized in that, The method includes: Acquire stored graph data, which is used to characterize the business data of various business objects of the enterprise and the relationships between the various business objects; In response to a user object's dialogue message being a business query type, the dialogue message is analyzed and processed to obtain query analysis results, which include the target business object and its corresponding data query conditions. Obtain the data query permission information of the user object, and generate a query instruction based on the query analysis results and the data query permission information; According to the query instruction, query the business data of the target business object in the map data to obtain the query result; Based on the query results, a feedback message is generated for the dialogue message and returned to the user object.

2. The method according to claim 1, characterized in that, The dialogue message responding to the user object is a business query type. The dialogue message is analyzed and processed to obtain query analysis results, including: Obtain the user object's historical dialogue messages, wherein the historical dialogue messages are received sequentially adjacent to the dialogue messages; The dialogue messages are reconstructed based on the historical dialogue messages to obtain reconstructed messages, and the reconstructed messages have the same meaning as the original dialogue messages. The reconstructed message is disassembled and analyzed to obtain the query analysis results.

3. The method according to claim 1, characterized in that, The step of obtaining the data query permission information of the user object and generating a query instruction based on the query analysis results and the data query permission information includes: A query script is generated based on the query analysis results. The query script is used to guide the generation of the query instruction. The query script includes query keywords corresponding to the target business object and the data query conditions. Obtain the stored scalar dictionary, which includes scalar strings corresponding to the various business objects respectively; The query script is executed to perform semantic analysis on the query keywords and scalar strings in the scalar dictionary, and to generate a query statement that matches the query keywords. The query instruction is generated by combining the query statement and the data query permission information.

4. The method according to claim 3, characterized in that, The execution of the query script, performing semantic analysis on the query keywords and scalar strings in the scalar dictionary, and generating a query statement matching the query keywords, includes: Obtain a vector library corresponding to the scalar dictionary. The vector library includes multiple feature vectors obtained by extracting features from the scalar strings corresponding to the various business objects. The i-th scalar string in the scalar dictionary corresponds to the i-th feature vector in the vector library, where i is a positive integer. Feature extraction is performed on the query keywords to obtain a query feature vector; Calculate the matching degree between the query feature vector and each of the plurality of feature vectors; Based on the scalar string corresponding to at least one feature vector whose matching degree meets the preset matching requirements, a query statement matching the query keyword is generated.

5. The method according to claim 3, characterized in that, The method further includes: If an execution error is detected during the execution of the query script, error information is obtained, which is used to indicate the cause of the error in the query script. The query script is updated based on the anomaly information to obtain the updated query script; Execute the updated query script.

6. The method according to claim 5, characterized in that, The step of updating the query script based on the anomaly information to obtain the updated query script includes: Obtain update records, which include the cumulative number of times the query script has been updated and the historical update method for each update; If the cumulative number of times is less than or equal to a preset number of times threshold, the query script is updated using a first update method to obtain the updated query script, wherein the first update method is different from the historical update method.

7. The method according to claim 1, characterized in that, The method further includes: If the message type of the dialogue message is a dialogue type, a reply content is generated based on the dialogue message; The reply content is returned to the user object.

8. An electronic device comprising a memory, one or more processors, and a computer program stored in the memory and executable on the one or more processors, characterized in that, When the one or more processors execute the computer program, the electronic device performs the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 7.

Images