Intelligent customer service query system and method based on natural language understanding

Abstract

The application provides an intelligent customer service query system and method based on natural language understanding, relates to the technical field of natural language processing, extracts a query intention and a core entity of a natural language query request input by a user end; then performs hierarchical decomposition on the query intention, and further constructs a query semantic tree according to a semantic association relationship between the hierarchical decomposition result and the core entity; generates a decision tensor representing a query path priority according to a node semantic weight of the query semantic tree and an access delay feature of a multi-source database; further adjusts an access order and a connection strategy of the multi-source data through the decision tensor and a dynamically updated query cost model, obtains a query execution link adapted to a current query request; and calls a corresponding data source interface to perform data retrieval and integration operation according to the query execution link, and obtains a target result set responding to a user query demand. The scheme of the application can realize optimal cost retrieval of multi-source data based on natural language.

Description

Technical Field

[0001] This application relates to the field of natural language processing technology, and more specifically, to an intelligent customer service query system and method based on natural language understanding. Background Technology

[0002] In modern information systems, enterprises and organizations face increasingly diverse data sources, including structured databases, semi-structured logs, and real-time sensor data. Traditional data query methods typically rely on fixed Structured Query Language (SQL) or Application Programming Interface (API), which are complex to operate and require high levels of user expertise, making it difficult to directly support natural language queries. With the development of artificial intelligence and natural language processing technologies, users hope to be able to directly retrieve the data they need in a natural language manner, thereby improving the convenience of data acquisition and the efficiency of business decision-making, and promoting the popularization and development of data-driven applications.

[0003] Existing multi-source data query technologies generally suffer from insufficient optimization of path selection and access costs when implementing natural language retrieval. Specifically, when processing cross-database queries, systems often access data sources in a fixed order or with a single priority, ignoring the semantic importance of different nodes and differences in database access latency. This results in lengthy query paths, high response latency, and significant waste of computational resources. Performance bottlenecks are particularly pronounced in scenarios involving large amounts of data and complex query intents. Due to the lack of comprehensive consideration of query intent hierarchy, entity relationships, and access latency, existing technologies cannot achieve optimal access costs and execution efficiency while ensuring query accuracy. Therefore, achieving optimal cost retrieval of multi-source data based on natural language has become a challenging problem for the industry. Summary of the Invention

[0004] This application provides an intelligent customer service query system and method based on natural language understanding, which can achieve optimal cost retrieval of multi-source data based on natural language.

[0005] Firstly, this application provides an intelligent customer service query method based on natural language understanding, including:

[0006] In response to the intelligent customer service receiving a natural language query request from the user, the query intent and core entity of the natural language query request are extracted, and it is determined whether the core entity matches a preset multi-source database. If it matches, the natural language query request is marked as an executable query.

[0007] In response to a natural language query request being marked as an executable query, the query intent is hierarchically deconstructed, and then a query semantic tree is constructed based on the hierarchical deconstruction results and the semantic relationships between core entities.

[0008] A decision tensor representing the priority of the query path is generated based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database.

[0009] By adjusting the access order and connection strategy of multi-source data through the decision tensor and dynamically updated query cost model, a query execution link adapted to the current query request is obtained.

[0010] Based on the query execution chain, the corresponding data source interface is called to perform data retrieval and integration operations to obtain the target result set in response to the user's query requirements.

[0011] In some embodiments, the natural language query request refers to a query instruction entered by the user in natural language.

[0012] In some embodiments, extracting the query intent and core entities of a natural language query request specifically includes:

[0013] Natural language query requests are preprocessed to remove redundant characters, modal particles, and repetitive expressions, resulting in clean query text.

[0014] The query text is semantically recognized by a pre-trained intent classification model, and then the query intent of the natural language query request is output.

[0015] The core entities in the query text are extracted using a pre-trained entity recognition model. The core entities include entity name, entity attributes, and domain information.

[0016] In some embodiments, determining whether the core entity matches a preset multi-source database specifically includes:

[0017] The semantic matching degree between core entities and database entities is determined based on a pre-defined entity metadata dictionary;

[0018] When the semantic matching degree exceeds the set threshold and the required query attribute exists in the matching database, the matching is confirmed to be valid, and a matching dataset corresponding to the core entity is formed.

[0019] In some embodiments, the process of hierarchically deconstructing the query intent and then constructing a query semantic tree based on the hierarchical deconstruction results and the semantic relationships between core entities specifically includes:

[0020] The query intent is hierarchically divided to determine the hierarchical structure of the main graph and sub-intents, wherein the main graph corresponds to the core objective of the query, and the sub-intents correspond to the intermediate conditions required to achieve the core objective.

[0021] Extract the semantic relationships between core entities, and then determine the semantic relationship strength between the corresponding core entities based on the semantic relationships;

[0022] A query semantic tree is constructed using a hierarchical query intent as the trunk framework, core entities as tree nodes, semantic relationships between core entities as connecting edges, and the semantic relationship strength between core entities as connecting weights. Each node contains an entity identifier, the corresponding intent level, and the weight parameters of the connecting edges.

[0023] In some embodiments, generating a decision tensor representing the priority of query paths based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database specifically includes:

[0024] The semantic weight of each node is determined based on the intent level of the nodes in the query semantic tree and the semantic association strength between adjacent nodes.

[0025] Construct an access latency feature matrix for the multi-source database based on its historical access records.

[0026] Multiple query paths are generated based on the query semantic tree and the access priority of the multi-source database;

[0027] The semantic weights of each node are associated and mapped with the access delay feature matrix;

[0028] Based on the association mapping results and all query paths, a decision tensor representing the priority of the query path is determined, where the tensor element values ​​represent the comprehensive priority of the corresponding query path.

[0029] In some embodiments, the data retrieval and integration operations are performed by calling the corresponding data source interface according to the query execution chain to obtain the target result set in response to the user's query requirements, specifically including:

[0030] Data source interface parameters are extracted by parsing the query execution chain;

[0031] The API is called sequentially according to the access order to obtain the raw data, and the raw data is then subjected to format standardization and data cleaning.

[0032] The processed raw data is integrated and semantically validated. If the validation fails, the search is repeated until the target result set that meets the user's query requirements is obtained.

[0033] Secondly, this application provides an intelligent customer service query system based on natural language understanding, comprising:

[0034] The receiving module is used to receive natural language query requests input by users in the intelligent customer service terminal, extract the query intent and core entity of the natural language query request, determine whether the core entity matches the preset multi-source database, and if it matches, mark the natural language query request as an executable query.

[0035] The processing module is used to perform hierarchical deconstruction of the query intent after a natural language query request is marked as an executable query, and then construct a query semantic tree based on the hierarchical deconstruction results and the semantic relationships between core entities.

[0036] The processing module is also used to generate a decision tensor representing the priority of the query path based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database.

[0037] The processing module is also used to adjust the access order and connection strategy of multi-source data through the decision tensor and the dynamically updated query cost model to obtain a query execution link that adapts to the current query request.

[0038] The execution module is used to call the corresponding data source interface according to the query execution chain to perform data retrieval and integration operations, and obtain the target result set in response to the user's query requirements.

[0039] Thirdly, this application provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described intelligent customer service query method based on natural language understanding.

[0040] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described intelligent customer service query method based on natural language understanding.

[0041] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects:

[0042] In this embodiment, after the intelligent customer service terminal receives a natural language query request input from the user terminal, the query intent and core entities of the natural language query request are extracted. It is determined whether the core entities match a preset multi-source database. If they match, the natural language query request is marked as an executable query. After the natural language query request is marked as an executable query, the query intent is hierarchically deconstructed, and then a query semantic tree is constructed based on the hierarchical deconstruction results and the semantic relationships between the core entities. A decision tensor representing the priority of the query path is generated based on the semantic weights of the nodes in the query semantic tree and the access latency characteristics of the multi-source database. The access order and connection strategy of the multi-source data are adjusted through the decision tensor and a dynamically updated query cost model to obtain a query execution link adapted to the current query request. Data retrieval and integration operations are performed by calling the corresponding data source interface according to the query execution link to obtain a target result set responding to the user's query needs.

[0043] Therefore, this application adjusts the access order and connection strategy of multi-source data through decision tensors and dynamically updated query cost models to obtain a query execution chain. Then, based on the query execution chain, it calls the corresponding data source interface to perform data retrieval, obtaining a target result set responding to the user's query needs. First, after receiving the user's natural language query request, it extracts the semantic information in the query text in a structured manner through text preprocessing, intent classification, and entity recognition. This accurately identifies the query target and core entities, providing high-precision input for subsequent query path generation, which is the foundation for ensuring the integrity and correctness of the query semantics. Second, based on the matching results of core entities and multi-source databases, and the hierarchical deconstruction of query intent, a query semantic tree is constructed. This represents the query intent, entities, and their semantic relationships in a tree structure, clarifying the logical hierarchy and entity dependencies of the query request, providing a scientific basis for query path planning, and improving the controllability and interpretability of path selection in multi-source queries. Then, combined with the query language... The semantic weights of semantic tree nodes and the multi-source database access latency features generate a decision tensor. A dynamically updated query cost model is used to optimize the database access order and connection strategy, achieving comprehensive priority evaluation and optimal scheduling of multi-source data retrieval paths. This minimizes query latency and system resource consumption while ensuring semantic accuracy, thus improving overall execution efficiency. Finally, the generated query execution chain is parsed to call the corresponding data source interface for data retrieval and integration operations. Semantic verification and consistency checks are performed on the integration results, achieving automated integration of multi-source heterogeneous data and ensuring the completeness and accuracy of the results. In summary, this application's solution constructs a node semantic weight-driven query semantic tree by deconstructing the user's natural language query request at the intent level and extracting core entities. Based on this semantic tree and the multi-source database access latency features, a decision tensor is generated. Combined with a dynamic query cost model, the multi-source data access order and connection strategy are optimized, thereby achieving efficient integration and optimal cost retrieval of multi-source data. Attached Figure Description

[0044] Figure 1 This is an exemplary flowchart of an intelligent customer service query method based on natural language understanding, as shown in some embodiments of this application.

[0045] Figure 2 This is a schematic diagram illustrating the process of constructing a query semantic tree according to some embodiments of this application;

[0046] Figure 3 This is a flowchart illustrating the process of determining the decision tensor according to some embodiments of this application;

[0047] Figure 4 This is a schematic diagram of the structure of an intelligent customer service query system based on natural language understanding, according to some embodiments of this application;

[0048] Figure 5 This is a schematic diagram of the structure of a computer device implementing an intelligent customer service query method based on natural language understanding, according to some embodiments of this application. Detailed Implementation

[0049] To better understand the technical solution of this application, the technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0050] refer to Figure 1 The figure is an exemplary flowchart of an intelligent customer service query method based on natural language understanding, according to some embodiments of this application. The intelligent customer service query method based on natural language understanding mainly includes the following steps:

[0051] In step 101, in response to the intelligent client receiving a natural language query request input by the user, the query intent and core entity of the natural language query request are extracted, and it is determined whether the core entity matches a preset multi-source database. If it matches, the natural language query request is marked as an executable query.

[0052] It should be noted that, in this application, the intelligent customer service terminal refers to an interactive terminal used to receive user queries and generate intelligent responses; the user terminal refers to a terminal that initiates a query and interacts with the intelligent customer service; and the natural language query request refers to a query instruction entered by the user in natural language.

[0053] In some embodiments, extracting the query intent and core entities of a natural language query request can be achieved through the following steps:

[0054] Natural language query requests are preprocessed to remove redundant characters, modal particles, and repetitive expressions, resulting in clean query text.

[0055] The query text is semantically recognized by a pre-trained intent classification model, and then the query intent of the natural language query request is output.

[0056] The core entities in the query text are extracted using a pre-trained entity recognition model. The core entities include entity name, entity attributes, and domain information.

[0057] It should be noted that the query intent in this application refers to the core objective expressed by the user through a natural language query; the core entity in this application is an object used to locate and extract key information in the query, enabling the system to accurately match relevant data sources and obtain the required content; the intent classification model in this application is a type of model used to identify "what the user wants to do" in a natural language query. Its technical principle is to extract semantic features of the text through deep learning and map them to predefined intent categories. A common method is to obtain contextual semantic representations based on pre-trained language models (such as ERNIE or DistilBERT), and then connect fully connected layers to calculate the probability distribution of each intent, taking the highest probability as the final intent; the entity recognition model in this application is used to locate and label key information points in the query text. Its technical principle is to combine semantic representation and sequence labeling algorithms to identify entity boundaries and types in the text word by word. A common method is based on the BERT-BiLSTM-CRF framework, where BERT extracts deep semantic features, BiLSTM captures word order contextual relationships, and the CRF layer ensures the legality of the output label sequence, thereby achieving accurate extraction of entity names, attributes, and domain information.

[0058] In specific implementation, text preprocessing is performed on the natural language query request to remove redundant characters, modal particles, and repeated expressions. The following methods can be used to obtain the cleaned query text: Redundant characters in the query request can be filtered out using regular expressions, such as meaningless special symbols (#, @, etc.), extra spaces, or garbled characters, and only valid content such as text and numbers is retained. Then, through a publicly available Chinese basic stopword list, such as a general list containing modal particles like "ah, ne, ba, o", the modal particles in the text are directly filtered out. Finally, for repeated expressions, a simple method of traversing each word can be used. For example, when encountering consecutive repeated words or short sentences, only one of them is retained, and the cleaned query text can be quickly obtained. The entire process does not require complex technologies and can be achieved using only conventional text processing tools. The semantic recognition of the query text is performed through a pre-trained intent classification model, and then the query intent of the natural language query request is output. The following methods can be used to achieve this: A lightweight pre-trained model can be selected. For example, ERNIE-3.0-base is used for Chinese, and DistilBERT is used for English. Then, it is fine-tuned using a labeled query intent dataset. Specifically, during operation, the cleaned query text can be first converted into input identifiers (Identifiers, IDs) through the tokenizer provided by the model, and then input into the fine-tuned model. The model outputs the probability distribution of each intent category through a fully connected layer, and the category with the highest probability is taken as the query intent. It should be further noted that the cross-entropy loss function and the Adam optimizer can be used during the model fine-tuning process. This fine-tuning process is a conventional training method in the field of natural language processing and will not be elaborated here. The core entities in the query text are extracted through a pre-trained entity recognition model. The following methods can be used to achieve this: The well-known BERT-BiLSTM-CRF model can be used to extract the core entities in the query text. Among them, BERT is responsible for extracting text semantic features, BiLSTM can capture context dependencies, and CRF processes label constraints. After training the model with entity data labeled in the IOB format, the cleaned text is input into the model, and the model outputs the entity labels for each token. According to the label sequence, token combinations with consecutive identical labels are extracted. For example, the combination of "B-entity name" + "I-entity name" forms the entity name, the combination of "B-attribute" + "I-attribute" forms the entity attribute, and "B-field" corresponds to the field information. Finally, a core entity set containing entity names, attributes, and fields is obtained.

[0059] In some embodiments, the following steps can be used to determine whether the core entity matches a preset multi-source database:

[0060] Determine the semantic matching degree between the core entity and the database entity based on a preset entity metadata dictionary;

[0061] When the semantic matching degree exceeds the set threshold and the required query attribute exists in the matching database, the matching is confirmed to be valid, and a matching dataset corresponding to the core entity is formed.

[0062] It should be noted that the semantic matching degree in this application is an indicator that measures the semantic similarity between the core entities in the query text and the entities in the database.

[0063] In specific implementation, determining the semantic matching degree between core entities and database entities based on a pre-defined entity metadata dictionary can be achieved in the following way: First, an entity metadata dictionary needs to be constructed. This dictionary pre-stores the entity names, aliases, synonyms, attribute fields, and domain tags of each database, typically maintained in the form of relational tables or key-value mappings. After obtaining the core entity in the user query, it is first processed into word vectors, for example, using Word2Vec to represent words as low-dimensional vectors. Then, the similarity score between the core entity and the entities in the dictionary is calculated using cosine similarity. Finally, the similarity score is normalized, and the normalized result can be used as the basis for determining the semantic matching degree between the core entity and the entities in the dictionary. The semantic matching degree between the core entity and the database entity is determined. When the semantic matching degree exceeds a set threshold and the required query attribute exists in the matching database, the matching is confirmed as valid, and a matching dataset corresponding to the core entity is formed. This can be achieved in the following way: For each semantic matching degree, the semantic matching degree is compared with the preset threshold. If the semantic matching degree exceeds the threshold, the next step of verification is performed. In the verification stage, the query attribute required by the core entity is checked one by one to see if it exists in the corresponding entity field of the candidate database. This process can be completed directly by matching through dictionary index. If the field coverage is complete, the matching is confirmed as valid, and the entity and the corresponding database table and field form a structured matching dataset.

[0064] In step 102, in response to the natural language query request being marked as an executable query, the query intent is hierarchically deconstructed, and then a query semantic tree is constructed based on the hierarchical deconstruction results and the semantic relationships between core entities.

[0065] In some embodiments, reference Figure 2 As shown in the figure, this is a flowchart illustrating the process of constructing a query semantic tree in some embodiments of this application. In this embodiment, the query intent is hierarchically deconstructed, and the query semantic tree is constructed based on the hierarchical deconstruction results and the semantic relationships between core entities. This can be achieved by the following steps:

[0066] In step 1021, the query intent is hierarchically divided to determine the hierarchical structure of the main graph and sub-intents, wherein the main graph corresponds to the core target of the query, and the sub-intents correspond to the intermediate conditions required to achieve the core target.

[0067] In step 1022, the semantic relationships between core entities are extracted, and then the semantic relationship strength between corresponding core entities is determined based on the semantic relationships.

[0068] In step 1023, a query semantic tree is constructed with a hierarchical query intent as the trunk framework, core entities as tree nodes, semantic relationships between core entities as connecting edges, and semantic relationship strength between core entities as connecting weights. Each node contains entity identifier, corresponding intent level, and weight parameters of connecting edges.

[0069] It should be noted that the hierarchical deconstruction in this application refers to dividing the query intent into different levels according to the primary and secondary relationships, so as to distinguish the core objective from the intermediate conditions required to achieve the objective; the semantic association strength is an indicator that measures the degree of semantic correlation between different core entities in the query; the query semantic tree in this application is a structure tree used to represent the semantic relationship and hierarchical structure between the query intent and the core entities.

[0070] In practice, the query intent is hierarchically divided, and the hierarchical structure of the idea graph and sub-intents is determined in the following way: dependency parsing tools such as the open-source Stanford can be used. The parser performs syntactic structure analysis on the query text, extracting core predicate phrases as the main intent. For example, in the request "Query the quarterly sales revenue of a certain product," "Query sales revenue" can be identified as the main intent. The conditions that modify or limit the main intent are then broken down into sub-intents, such as "a certain product" and "quarterly," which can be sub-intents respectively. By setting clear rules—that is, the main intent corresponds to the final goal, and the sub-intents correspond to the necessary conditions for achieving the goal—a hierarchical framework of "main intent—sub-intent" is formed. Extracting the semantic relationships between core entities and determining the semantic association strength between corresponding core entities can be achieved in the following way: Core entities can be input into a pre-trained lightweight relation classification model, such as a relation classifier fine-tuned based on BERT-base. The model outputs the association type between entity pairs, such as limiting relations, attribute relations, or contrast relations. While obtaining the association type, the association strength needs to be calculated. This involves first converting each core entity into word vectors using Word2Vec and then calculating semantic similarity using cosine similarity, with the result between 0 and 1. To further enhance accuracy, further analysis is needed... The co-occurrence distance of entities in the query text is used to determine the semantic association strength. Closer distances indicate stronger associations and thus receive higher weights. The semantic similarity and co-occurrence distance are then weighted and summed to obtain the overall semantic association strength. For example, when the semantic similarity is 0.8 and the co-occurrence distance is 1, the final association strength can be set to 0.85. It should be noted that the weighting coefficients for semantic similarity and co-occurrence distance can be set based on historical data or expert experience. The query semantic tree can be constructed using a hierarchical query intent as the trunk framework, core entities as tree nodes, semantic associations between core entities as connecting edges, and the semantic association strength between core entities as the connection weight. This can be achieved by using a hierarchical intent framework as the foundation, with the main intent graph as the root node, sub-intents as second-level nodes, and core entities attached to their corresponding intent nodes. Nodes are connected through associations, and the weight of the connecting edges is labeled by the association strength. Each node is stored in a dictionary structure, including the entity identifier, the corresponding intent level, and the edge weight parameters. The final query semantic tree can be stored in JSON format, which can intuitively display the hierarchical structure and semantic associations between the query intent and core entities.

[0071] In step 103, a decision tensor representing the priority of the query path is generated based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database.

[0072] In some embodiments, reference Figure 3As shown in the figure, this is a flowchart illustrating the process of determining the decision tensor in some embodiments of this application. In this embodiment, the generation of the decision tensor representing the priority of the query path based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database can be achieved by the following steps:

[0073] In step 1031, the semantic weight of each node is determined based on the intent level of the nodes in the query semantic tree and the semantic association strength between adjacent nodes.

[0074] In step 1032, an access latency feature matrix of the multi-source database is constructed based on the historical access records of the multi-source database.

[0075] In step 1033, multiple query paths are generated based on the query semantic tree and the access priority of the multi-source database;

[0076] In step 1034, the node semantic weights of each node are associated and mapped with the access delay feature matrix;

[0077] In step 1035, a decision tensor representing the priority of a query path is determined based on the association mapping result and all query paths, wherein the tensor element values ​​represent the comprehensive priority of the corresponding query path.

[0078] It should be noted that the node semantic weight in this application is an indicator used to quantify the importance of each node in the query semantic tree in realizing the query intent; the access latency feature in this application refers to the performance indicator of the response time of the multi-source database when processing query requests; the access latency feature matrix in this application is a two-dimensional data structure used to record the response latency features of the multi-source database under different access conditions; and the decision tensor in this application is a tensor used to characterize the comprehensive priority of each query path, which is a multi-dimensional data structure that can guide the query execution order and strategy selection.

[0079] In specific implementation, determining the semantic weight of each node based on the intent level of the nodes in the query semantic tree and the semantic association strength between adjacent nodes can be achieved in the following way: a weighted calculation method can be used, combining the intent level and the semantic association strength between adjacent nodes. Fixed weights are preset for intent nodes at different levels; for example, main graph nodes are assigned higher base weights, and sub-intent nodes are assigned relatively lower base weights. Then, a weighted sum is performed based on the semantic association strength between adjacent nodes, followed by normalization. The normalized value is used as the semantic weight of the corresponding node. Based on the historical access records of the multi-source database, a multi-source database is constructed. The access latency feature matrix can be implemented as follows: When constructing the access latency feature matrix for multiple databases, it can be obtained from historical access records. Commonly used indicators include average response time, percentile latency, and peak access latency. Each database corresponds to one row, and each type of latency indicator corresponds to one column, ultimately forming a two-dimensional matrix that clearly characterizes the access performance features of each database. Associating and mapping the semantic weights of each node with the access latency feature matrix and generating multiple query paths based on the query semantic tree and the access priority of the multiple databases can be implemented as follows: The matching relationship between core entities and databases can be utilized to map the semantic weights of nodes to the access latency feature matrix. The semantic layer is bound to the latency features of its corresponding database to achieve effective connection between the semantic layer and the data layer. Furthermore, query paths are generated based on the query semantic tree. Starting from the root node, the system traverses the child nodes sequentially according to the semantic association strength between them, from high to low. Combining the matching between nodes and the database, a query path covering all necessary nodes is gradually generated, ensuring the completeness of the query target. The decision tensor representing the priority of the query path, based on the association mapping results and all query paths, can be implemented as follows: a three-dimensional structure is used, including path number, total semantic weight, and total latency cost, to construct the decision tensor representing the priority of the query path. The total semantic weight of the path is accumulated... The semantic weights of all nodes in the path are added together. The total latency cost is obtained by accumulating the average latency of the databases involved in the path. The overall priority is calculated by setting a weighted formula, which usually combines the positive contribution of semantic weights with the negative constraint of latency cost. That is, overall priority = total semantic weight × weight coefficient - normalized total latency cost × (1 - weight coefficient). The weight coefficient can be set according to historical data. In this application, it can be set to 0.6. The larger the final tensor element value, the higher the priority of the path. The method of this application is not only simple to implement, but also can intuitively reflect the trade-off between semantic importance and access cost of multi-source query paths.

[0080] In step 104, the access order and connection strategy of multi-source data are adjusted by the decision tensor and the dynamically updated query cost model to obtain a query execution link that adapts to the current query request.

[0081] In some embodiments, adjusting the access order and connection strategy of multi-source data through the decision tensor and dynamically updated query cost model to obtain a query execution chain adapted to the current query request can be achieved through the following steps:

[0082] The query cost of each query path is determined using a query cost model;

[0083] The initial access order is determined based on the decision tensor and the query cost of each query path;

[0084] Analyze the data relationships between databases in the initial access sequence, extract the data overlap of the accessed data, and then select a connection strategy based on the data overlap and query requirements;

[0085] The initial access order and connection strategy are optimized by simulating execution until the total cost is lower than a preset threshold. The resulting query link is then used as the query execution link adapted to the current query request.

[0086] It should be noted that the query cost in this application is an indicator that measures the resource consumption and efficiency overhead required to execute a certain query path; the data overlap is an indicator that measures the proportion of duplication or intersection between data records stored in different databases; and the query execution chain refers to the specific data processing flow that accesses multiple source databases in an optimized order and applies corresponding connection strategies to complete the user query.

[0087] It should also be noted that the query cost model in this application is a computational model used to quantify the execution cost of each query path. Its function is to provide a basis for path optimization for the system. Its technical principle is to combine the database access performance and query semantic importance involved in the path, and obtain a comprehensive cost value through weighted calculation. In specific implementation, firstly, the semantic weight of each node in the path and the access latency of the matching database are extracted based on the decision tensor. The semantic weight is reflected as an importance indicator of the path to the realization of the query intent, and the access latency is reflected as a performance cost indicator. Then, the cost value of each query path is calculated through linear weighting or a preset formula. The lower the value obtained, the higher the path execution efficiency and the better the semantic coverage. The model can be dynamically updated to reflect changes in database load and path adjustments in real time, realizing the optimized selection of multi-source data access order and connection strategy, ensuring that the query execution link is efficient and semantically complete.

[0088] In specific implementation, determining the query cost of each query path through the query cost model can be achieved in the following way: The database access latency feature and the average semantic weight of nodes are used as input parameters to the query cost model. The access latency can be taken as the average response time, which is then normalized to a dimensionless feature value, i.e., the normalized access latency feature value. The average semantic weight of nodes is the average of the weights of all nodes in the path, and can be calculated in the query cost model using the following formula: Query Cost = Normalized Access Latency Feature Value / Average Semantic Weight of Nodes. Determining the initial access order based on the decision tensor and the query cost of each query path can be achieved in the following way: The ranking score is calculated based on the comprehensive priority in the cost and decision tensor. In practice, the comprehensive priority of each query path can be obtained from the decision tensor, and then the ranking value of each path can be calculated using the formula: Ranking Score = (1 - Query Cost) × 0.6 + Comprehensive Priority × 0.4. Further, the paths are sorted in descending order using Python's `sorted` function to obtain the initial access order. The data association between databases in the initial access order is analyzed to extract the data overlap. Based on the data overlap and query requirements, a join strategy can be selected. This can be achieved by first using the core primary key field in the database as a comparison benchmark, and then using Jaccard similarity... The algorithm calculates the data overlap. The formula for calculating the data overlap is the number of intersections of the primary keys of the two databases divided by the number of unions. If the data overlap is greater than 0.6, it indicates high data overlap, and hash joins are suitable to improve processing efficiency. If the data overlap is less than 0.3, it indicates low data overlap, and nested loop joins are preferable to avoid additional preprocessing overhead. When the data overlap is in the middle range, merge joins are chosen as a compromise. The initial access order and the join strategy are optimized by simulating execution until the total cost is lower than a preset threshold. The resulting query link is used as the query execution link adapted to the current query request. This can be achieved in the following way: the initial access order can be... The order and join strategy are taken as inputs. The total cost is calculated based on the query cost model, which is the sum of the query costs of all paths. If the total cost exceeds a preset threshold, adjustments are required. These adjustments may include moving databases with higher latency to the back of the queue or reselecting join strategies for specific data overlap. This optimization process is performed through iterative simulation until the total cost is below the threshold. The final combination of access order and join strategy is the query execution chain adapted to the current query request. It can be recorded in the form of a structured list. For example, database 1 uses hash join, database 3 uses nested loop join, and database 2 uses merge join. This implementation process is intuitive and logically clear, and can effectively balance semantic importance and access efficiency.

[0089] In step 105, the corresponding data source interface is called according to the query execution chain to perform data retrieval and integration operations, and a target result set in response to the user's query needs is obtained.

[0090] In some embodiments, the following steps can be used to perform data retrieval and integration operations by calling the corresponding data source interface according to the query execution chain to obtain the target result set in response to the user's query requirements:

[0091] Data source interface parameters are extracted by parsing the query execution chain;

[0092] The API is called sequentially according to the access order to obtain the raw data, and the raw data is then subjected to format standardization and data cleaning.

[0093] The processed raw data is integrated and semantically validated. If the validation fails, the search is repeated until the target result set that meets the user's query requirements is obtained.

[0094] It should be noted that the integration operation in this application refers to the operation of merging, associating, and uniformly processing raw data from different data sources according to query requirements and connection strategies.

[0095] In specific implementation, extracting data source interface parameters by parsing the query execution chain can be achieved in the following way: During the parameter parsing stage, the data source interface content stored in JSON structured format in the query execution chain is parsed one by one. The chain record usually contains the database identifier, interface address, and the set of parameters required by the interface. Python's JSON library can be used directly for parsing, extracting the interface address, required parameter name, and corresponding value one by one, and confirming the format of the extracted parameters. For example, the time field is converted into the standard date string "YYYY-MM-DD" to ensure that it meets the input requirements of the interface. The raw data is obtained by calling the interface in the access order, and the raw data is then standardized and cleaned. This can be achieved in the following way: Each interface can be called step by step in the parsed access order. The interface access is completed using Python's requests library. GET or POST request methods are used according to the interface type. The parameters are submitted in dictionary form. The raw data returned by the interface may be in JSON or CSV format. In this case, the Pandas library is used for standardization, and the corresponding reading function is called to convert it into a DataFrame table. The data is further cleaned by removing duplicate records, filling in missing values, and handling outliers. Missing values ​​can be replaced with zero or business default values, and outliers can be identified and removed using the IQR rule, ultimately resulting in complete and clean structured data. Data integration and semantic validation are then performed on the processed raw data. If the validation fails, the query is repeated until the target result set that meets the user's query requirements is obtained. This can be achieved as follows: In the integration and semantic validation stage, multi-source data can be integrated according to the preset connection strategy in the query execution chain. A common practice is to use Pandas' merge function to implement hash joins or merge joins based on core primary key fields, such as product ID or user ID, to obtain a complete dataset covering the query requirements. In the semantic validation stage, conditional judgments are used to check against the user's query requirements to confirm whether the result set contains key fields and verify the correctness of numerical logic. For example, sales must be greater than or equal to zero. If the validation fails, the interface parameter configuration needs to be traced back to check for omissions or errors and a re-request is made until a dataset that meets the query requirements is generated. Finally, the integrated DataFrame is converted into JSON or tabular format and returned as the final query result.

[0096] On the other hand, in some embodiments, this application provides an intelligent customer service query system based on natural language understanding, see reference. Figure 4 The figure is a schematic diagram of the structure of an intelligent customer service query system based on natural language understanding, according to some embodiments of this application. The intelligent customer service query system based on natural language understanding includes: a receiving module 401, a processing module 402, and an execution module 403, which are described below:

[0097] The receiving module 401 in this application is mainly used to receive natural language query requests input by the user terminal in the intelligent customer service terminal, extract the query intent and core entity of the natural language query request, determine whether the core entity matches the preset multi-source database, and if it matches, mark the natural language query request as an executable query.

[0098] Processing module 402, in this application, is mainly used to respond to a natural language query request being marked as an executable query, to perform hierarchical deconstruction of the query intent, and then construct a query semantic tree based on the hierarchical deconstruction result and the semantic relationship between core entities;

[0099] In this application, the processing module 402 is also used to generate a decision tensor representing the priority of the query path based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database.

[0100] In this application, the processing module 402 is also used to adjust the access order and connection strategy of multi-source data through the decision tensor and the dynamically updated query cost model to obtain a query execution link that adapts to the current query request.

[0101] The execution module 403 in this application is mainly used to call the corresponding data source interface according to the query execution link to perform data retrieval and integration operations, and obtain the target result set in response to the user's query requirements.

[0102] In addition, this application also provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described intelligent customer service query method based on natural language understanding.

[0103] In some embodiments, reference Figure 5 The figure is a schematic diagram of the structure of a computer device implementing a natural language understanding-based intelligent customer service query method according to some embodiments of this application. The natural language understanding-based intelligent customer service query method in the above embodiments can... Figure 5 The computer device shown is used to implement this, and the computer device 500 includes at least one processor 501, a communication bus 502, a memory 503, and at least one communication interface 504.

[0104] Processor 501 can be a general-purpose central processing unit (CPU) or an application-specific integrated circuit (ASIC).

[0105] The communication bus 502 can be used to transmit information between the aforementioned components.

[0106] Memory 503 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 503 may exist independently and be connected to processor 501 via communication bus 502. Memory 503 may also be integrated with processor 501.

[0107] The memory 503 stores program code that executes the solution of this application, and its execution is controlled by the processor 501. The processor 501 executes the program code stored in the memory 503. The program code may include one or more software modules. In the above embodiments, the intelligent customer service query method based on natural language understanding can be implemented by the processor 501 and one or more software modules in the program code in the memory 503.

[0108] Communication interface 504 uses any transceiver-like device to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0109] In a specific implementation, as one example, a computer device may include multiple processors, each of which may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0110] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can be a desktop computer, a portable computer, a network server, a handheld digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0111] In addition, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described intelligent customer service query method based on natural language understanding.

[0112] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0113] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for intelligent customer service inquiry based on natural language understanding, characterized in that, include: In response to the intelligent customer service receiving a natural language query request from the user, the query intent and core entity of the natural language query request are extracted, and it is determined whether the core entity matches a preset multi-source database. If it matches, the natural language query request is marked as an executable query. In response to a natural language query request being marked as an executable query, the query intent is hierarchically deconstructed, and then a query semantic tree is constructed based on the hierarchical deconstruction results and the semantic relationships between core entities. The query semantic tree is a structure tree used to represent the semantic relationships and hierarchical structure between the query intent and the core entities. A decision tensor representing the priority of the query path is generated based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database. By adjusting the access order and connection strategy of multi-source data using the decision tensor and dynamically updated query cost model, a query execution link adapted to the current query request is obtained. Based on the query execution chain, the corresponding data source interface is called to perform data retrieval and integration operations to obtain the target result set in response to the user's query requirements; Specifically, the process of hierarchically deconstructing the query intent and then constructing a query semantic tree based on the hierarchical deconstruction results and the semantic relationships between core entities includes: The query intent is hierarchically divided to determine the hierarchical structure of the main graph and sub-intents, wherein the main graph corresponds to the core objective of the query, and the sub-intents correspond to the intermediate conditions required to achieve the core objective. Extract the semantic relationships between core entities, and then determine the semantic relationship strength between the corresponding core entities based on the semantic relationships. A query semantic tree is constructed using a hierarchical query intent as the trunk framework, core entities as tree nodes, semantic relationships between core entities as connecting edges, and the semantic relationship strength between core entities as connecting weights. Each node contains an entity identifier, the corresponding intent level, and the weight parameters of the connecting edges.

2. The method as described in claim 1, characterized in that, The natural language query request refers to the query instruction entered by the user in natural language form.

3. The method as described in claim 1, characterized in that, Extracting the query intent and core entities from a natural language query request specifically includes: Natural language query requests are preprocessed to remove redundant characters, modal particles, and repetitive expressions, resulting in clean query text. The query text is semantically recognized by a pre-trained intent classification model, and then the query intent of the natural language query request is output. The core entities in the query text are extracted using a pre-trained entity recognition model. The core entities include entity name, entity attributes, and domain information.

4. The method as described in claim 1, characterized in that, Determining whether the core entity matches the preset multi-source database specifically includes: The semantic matching degree between core entities and database entities is determined based on a pre-defined entity metadata dictionary; When the semantic matching degree exceeds the set threshold and the required query attribute exists in the matching database, the matching is confirmed to be valid, and a matching dataset corresponding to the core entity is formed.

5. The method as described in claim 1, characterized in that, The generation of a decision tensor representing the priority of query paths based on the semantic weights of the nodes in the query semantic tree and the access latency characteristics of the multi-source database specifically includes: The semantic weight of each node is determined based on the intent level of the nodes in the query semantic tree and the semantic association strength between adjacent nodes. Construct an access latency feature matrix for the multi-source database based on its historical access records. Multiple query paths are generated based on the query semantic tree and the access priority of the multi-source database; The semantic weights of each node are associated and mapped with the access delay feature matrix; Based on the association mapping results and all query paths, a decision tensor representing the priority of the query path is determined, where the tensor element values ​​represent the comprehensive priority of the corresponding query path.

6. The method as described in claim 1, characterized in that, Based on the query execution chain, the corresponding data source interface is invoked to perform data retrieval and integration operations, resulting in a target result set that meets the user's query requirements. Specifically, this includes: Data source interface parameters are extracted by parsing the query execution chain; The API is called sequentially according to the access order to obtain the raw data, and the raw data is then subjected to format standardization and data cleaning. The processed raw data is integrated and semantically validated. If the validation fails, the search is repeated until the target result set that meets the user's query requirements is obtained.

7. An intelligent customer service query system based on natural language understanding, which performs queries using the method described in any one of claims 1 to 6, characterized in that, The system includes: The receiving module is used to receive natural language query requests input by users in the intelligent customer service terminal, extract the query intent and core entity of the natural language query request, determine whether the core entity matches the preset multi-source database, and if it matches, mark the natural language query request as an executable query. The processing module is used to perform hierarchical deconstruction of the query intent after a natural language query request is marked as an executable query, and then construct a query semantic tree based on the hierarchical deconstruction results and the semantic relationships between core entities. The processing module is also used to generate a decision tensor representing the priority of the query path based on the node semantic weights of the query semantic tree and the access latency characteristics of the multi-source database. The processing module is also used to adjust the access order and connection strategy of multi-source data through the decision tensor and the dynamically updated query cost model to obtain a query execution link that adapts to the current query request. The execution module is used to call the corresponding data source interface according to the query execution chain to perform data retrieval and integration operations, and obtain the target result set in response to the user's query requirements.

8. A computer device comprising a memory and a processor, the memory storing code, characterized in that, The processor is configured to acquire the code and execute the intelligent customer service query method based on natural language understanding as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the intelligent customer service query method based on natural language understanding as described in any one of claims 1 to 6.

Images