A knowledge category sub-packaging method and system

Abstract

The embodiment of the specification provides a knowledge category packaging method and system, relates to the online customer service technical field, and the technical points include the following: more than two knowledge categories are acquired; a graph is constructed by taking the knowledge categories as nodes and the association relationship of the knowledge categories as edges; graph embedding processing is performed on the graph to obtain node vectors corresponding to the knowledge categories; hierarchical clustering is performed on the knowledge categories based on the node vectors to obtain a tree structure reflecting a layer-by-layer aggregation process of the knowledge categories; and clustering clusters corresponding to more than two tree branches in the tree structure are taken as independent knowledge category packages respectively.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of online customer service, and in particular to a knowledge category packaging method and system. BACKGROUND

[0002] With the continuous development of online services, the role of online customer service is also increasingly important. For an Internet service platform, the more service items it involves, the broader the knowledge involved in user questions. In order to efficiently deal with online consultation of users, in some scenarios, the knowledge involved in service items under the platform can be packaged, and when a user question comes in, it can be divided into the corresponding package, and a dedicated customer service is responsible for answering. With the in-depth development of business, how to package knowledge has become a new technical problem. For example, unreasonable packaging can lead to user questions being difficult to be accurately divided into a unique knowledge package, and thus customer service efficiency is low or users cannot get satisfactory answers and other problems.

[0003] Therefore, some embodiments of the present specification provide a knowledge category packaging method and system. SUMMARY

[0004] One or more embodiments of the present specification provide a knowledge category packaging method, comprising: obtaining two or more knowledge categories; constructing a graph with the knowledge categories as nodes and the association relationship of the knowledge categories as edges; performing graph embedding processing on the graph to obtain node vectors corresponding to the knowledge categories; performing hierarchical clustering on the knowledge categories based on the node vectors to obtain a tree structure reflecting the layer-by-layer aggregation process of the knowledge categories; and taking the clustering clusters corresponding to two or more tree branches in the tree structure as independent knowledge category packages.

[0005] One or more embodiments of the present specification provide a knowledge category packaging system, comprising: an obtaining module configured to obtain two or more knowledge categories; a graph constructing module configured to construct a graph with the knowledge categories as nodes and the association relationship of the knowledge categories as edges; an embedding module configured to perform graph embedding processing on the graph to obtain node vectors corresponding to the knowledge categories; an aggregation module configured to perform hierarchical clustering on the knowledge categories based on the node vectors to obtain a tree structure reflecting the layer-by-layer aggregation process of the knowledge categories; and a packaging module configured to take the clustering clusters corresponding to two or more tree branches in the tree structure as independent knowledge category packages.

[0006] One or more embodiments of the present specification provide a storage medium for storing computer instructions, when at least part of the computer instructions are executed by a processor, the foregoing knowledge category packaging method is implemented.

[0007] This specification provides an apparatus, including a processor and a storage medium, wherein the storage medium stores computer instructions, and the processor is configured to execute at least a portion of the computer instructions to implement the aforementioned knowledge category subcontracting method. Attached Figure Description

[0008] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0009] Figure 1 These are schematic diagrams illustrating online customer service application scenarios based on some embodiments of this specification;

[0010] Figure 2 This is an exemplary flowchart of a knowledge category sub-packaging method according to some embodiments of this specification;

[0011] Figure 3 This is a schematic diagram of the long-tail distribution according to some embodiments of this specification;

[0012] Figure 4 This is a schematic diagram of a knowledge category-based graph constructed according to some embodiments of this specification;

[0013] Figure 5 This is a schematic diagram of a tree structure obtained by hierarchical clustering according to some embodiments of this specification;

[0014] Figure 6 This is a schematic diagram of the knowledge system illustrated by some embodiments of this specification;

[0015] Figure 7 This is a schematic block diagram of a knowledge category classification system based on some embodiments of this specification. Detailed Implementation

[0016] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0017] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0018] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0019] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0020] Customer service, also known simply as customer service, refers to the services provided to users (or customers) in specific service areas, including answering questions and resolving doubts. Online customer service is a technology that provides instant communication services to users through online media such as the internet and telephone. With the continuous development of online services, the role of online customer service is becoming increasingly important. It can be said that for a platform or organization providing customer service via the internet, online customer service is almost an indispensable part. For example, the aforementioned platform or organization could be an electronic consumption platform, an electronic payment platform, an online financial platform, etc. In specific scenarios, users can send questions to online customer service. These questions can be descriptions of the user's doubts and can include data or information in the form of text, images, voice, and / or video. Customer service can be human or intelligent. For example, a customer service robot can handle user questions, identify the semantic information or intent of the user's questions, and then push matching knowledge points to the user, allowing the user to resolve their doubts by viewing the knowledge points.

[0021] Figure 1 This is a schematic diagram of an online customer service application scenario according to some embodiments of this specification. Scenario 100 includes a processing device 110, clients 131, 132, 133..., and the processing device 110 and clients 131, 132, 133... communicate through network 120.

[0022] The processing device 110 may be deployed with the server-side of the aforementioned service platform; therefore, in some scenarios, the processing device can also be considered a server. The server-side may include software systems that implement various functions of the online service, and online customer service can be implemented on the server-side. As an example, the processing device 110 can handle user questions and then provide knowledge points matching the user's questions. The processing device 110 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, the processing device 110 may be implemented on a cloud platform. As an example only, the cloud platform may include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, inter-cloud, multi-cloud, etc., or any combination thereof.

[0023] The client can be implemented on user-side terminal devices such as laptops 131, desktop computers 132, and mobile devices 133. In some embodiments, mobile devices 133 may include smart home devices, wearable devices, smart mobile devices, virtual reality devices, augmented reality devices, etc., or any combination thereof. In some embodiments, smart home devices may include smart lighting devices, smart appliance control devices, smart monitoring devices, smart TVs, smart video cameras, walkie-talkies, etc., or any combination thereof. In some embodiments, wearable devices may include smart bracelets, smart shoes and socks, smart glasses, smart helmets, smart watches, smart clothing, smart backpacks, smart accessories, etc., or any combination thereof. In some embodiments, smart mobile devices may include smartphones, personal digital assistants (PDAs), gaming devices, navigation devices, POS devices, etc., or any combination thereof. In some embodiments, virtual reality devices and / or augmented reality devices may include virtual reality helmets, virtual reality glasses, virtual reality patches, augmented reality helmets, augmented reality glasses, augmented reality patches, etc., or any combination thereof. In some embodiments, the client may include an application corresponding to the server. Users can use the various functions of the online services provided by the service platform through the client, including its online customer service function. As an example, users can submit questions to the server through the client, and the server can provide the corresponding knowledge points to the client for the user to view.

[0024] For service platforms or institutions, the more services they offer, the broader the knowledge base of user inquiries. Taking online financial platforms as an example, their services may include user account management and online trading, with each segment encompassing numerous specific services. To efficiently handle online user inquiries, in some scenarios, the knowledge involved in the platform's services can be packaged. For instance, knowledge can be divided into multiple categories based on its internal logic, with each category corresponding to a branch of knowledge content. Furthermore, these knowledge categories can be further subdivided. When a user inquires, it can be assigned to the corresponding knowledge category package and answered by a dedicated customer service representative. For example, processing device 110 can use text classification models, semantic similarity calculations, or keyword matching to process user inquiries, assigning (or identifying) them to the corresponding knowledge category package and then dispatching the user's question to the appropriate customer service representative. For example, when a user question is submitted to processing device 110, after processing (such as identification or classification), it is determined that the user question involves several knowledge categories and the probability value of the user question hitting each of the aforementioned knowledge categories is obtained. Then, each probability value is aggregated (such as superimposed) according to the knowledge category package to which its corresponding knowledge category belongs, to obtain the probability value corresponding to the relevant knowledge category package, and then the question is assigned to the customer service of the knowledge category package with the highest probability value. As the business develops, how to package knowledge has become a new technical problem. For example, unreasonable packaging can make it difficult for user questions to be accurately classified into a unique knowledge package. For example, when a user question is submitted to processing device 110, after processing, it may be found that the user question involves or hits multiple knowledge categories, and these knowledge categories are distributed in different knowledge category packages. This phenomenon can be called cross-package questioning. When cross-category questions occur, user questions may be assigned to customer service representatives of inappropriate knowledge category packages, or they may be handled sequentially by customer service representatives of multiple knowledge category packages (or the user question may be transferred by multiple customer service representatives), leading to problems such as unsatisfactory answers for users or low customer service efficiency. For example, when a user question is submitted to processing device 110, after processing (such as identification or classification), the probability value of the user question belonging to knowledge category A is 0.1, the probability value of belonging to knowledge category B is 0.5, and so on. Finally, according to the aforementioned strategy, the user question is assigned to the customer service representative corresponding to knowledge category package 1. When the customer service representative handles the user question, they can confirm the actual knowledge category involved. Suppose the customer service representative determines that the current user question actually involves knowledge category C, then an identification relationship can be established between knowledge category C and knowledge categories A and B, specifically recorded as "knowledge category A (0.1) → knowledge category C" and "knowledge category B (0.5) → knowledge category C".The left side of the arrow represents the knowledge category identified by the user's question, while the right side represents the actual knowledge category involved in the user's question. The higher the probability value in the parentheses, the greater the probability that the user's question will be misidentified (e.g., by the identification or classification model). Misidentified user questions involve knowledge categories distributed across different knowledge category packages, which can lead to problems such as users not receiving satisfactory answers or low customer service efficiency.

[0025] In view of this, some embodiments of this specification provide a method and system for knowledge category subpackaging.

[0026] Figure 2 This is an exemplary flowchart of a knowledge category sub-package method according to some embodiments of this specification. Figure 2 The illustrated process 200 can be implemented by a processing device (such as processing device 110). In some embodiments, process 200 can be implemented by a knowledge category sub-packaging system 700 deployed on the processing device. Process 200 includes:

[0027] Step 210: Obtain two or more knowledge categories. In some embodiments, step 210 may be implemented by the acquisition module 710.

[0028] Knowledge can be categorized. For example, knowledge can be divided into multiple branches according to its internal logic, and knowledge categories can be general descriptions of knowledge under different branches. Intuitively, a knowledge category can be a title for a certain type of knowledge. For example, for a financial service platform or institution, the knowledge involved can be divided into knowledge categories such as financial management, account management, and online transactions from the perspective of service projects, or into knowledge categories such as financial product A, financial product B, and financial product C from the perspective of products. In some embodiments, knowledge categories can be obtained in advance and stored in the service platform's database or storage device, and the acquisition module 710 obtains them by accessing the database or storage device. Knowledge categories can be stored in the form of a set, which contains multiple knowledge categories related to the service platform.

[0029] In some embodiments, a smaller number of knowledge categories in the knowledge category set are hit (or mentioned) by users' questions significantly more frequently than the other knowledge categories, that is, the hit frequency or probability of knowledge categories in the knowledge category set exhibits the characteristics of a long-tail distribution. Figure 3This diagram illustrates a long-tail distribution based on some embodiments of this specification. The horizontal axis represents the knowledge categories in the set, and the vertical axis represents the frequency (or number of times) that a knowledge category was matched by user questions within a certain historical period. In the diagram, the number of knowledge categories to the left of the dashed line represents a relatively small percentage of the total number of knowledge categories in the set, such as less than the second threshold (e.g., 20%), but the number of times these knowledge categories were matched by user questions represents a relatively high percentage of the total number of times knowledge categories were matched in the set, such as greater than the first threshold (e.g., 50%). This portion of knowledge categories clusters at the head of the distribution curve and is referred to as the head categories. The number of knowledge categories to the right of the dashed line represents a relatively large percentage of the total number, but the number of times they were matched by user questions represents a relatively low percentage. This portion of knowledge categories forms the long tail of the distribution curve and is referred to as the long-tail categories.

[0030] In some embodiments, the knowledge categories can be subdivided based on the header categories in the collection. Therefore, the two or more knowledge categories obtained can come from the header categories in the collection.

[0031] In some embodiments, the two or more knowledge categories can be obtained from the following one or more knowledge categories: two or more knowledge categories commonly hit by user questions (i.e., knowledge categories involved in shared questions), knowledge categories identified by user questions and the knowledge categories they actually involve (i.e., knowledge categories with identification relationships), and knowledge categories involved in user questions handled sequentially by two or more customer service representatives (i.e., knowledge categories involved in transfer questions). These knowledge categories may overlap. For example, some of the two or more knowledge categories commonly hit by user questions may also be knowledge categories involved in user questions handled sequentially by two or more customer service representatives. Similarly, knowledge categories with identification relationships may also include knowledge categories involved in user questions handled sequentially by two or more customer service representatives. In some embodiments, the knowledge categories commonly hit, knowledge categories with identification relationships, and knowledge categories involved in transfer questions constitute the majority of the knowledge category set. It can be considered that these knowledge categories mainly fall within the aforementioned head categories. In addition, the shared questions, identification, and transfer relationships between these knowledge categories can further influence the sub-packaging of knowledge categories, helping to avoid the problems of cross-package shared questions and multiple transfers mentioned earlier.

[0032] Step 220: Construct a graph using knowledge categories as nodes and the relationships between knowledge categories as edges. In some embodiments, step 220 can be implemented by the graph construction module 720.

[0033] Figure 4This is a schematic diagram of a knowledge category-based graph constructed according to some embodiments of this specification. The nodes in the graph correspond to knowledge categories, and the edges reflect the relationships between the knowledge categories corresponding to the nodes at their ends. In some embodiments, the relationships between knowledge categories may include being commonly hit by user questions (or simply referred to as a shared question relationship), being involved in user questions handled sequentially by two or more customer service representatives (or simply referred to as a transfer relationship), identification relationships, etc. For example, Figure 4 In this framework, knowledge category A and knowledge category B have a transition relationship, knowledge category C and knowledge category D have a shared question relationship, and knowledge category B and knowledge category D have an identification relationship. In some embodiments, two knowledge categories can simultaneously possess two or more of the aforementioned relationships, such as knowledge category C and knowledge category E having both a transition relationship and an identification relationship. In some embodiments, the identification relationship and the transition relationship can have direction, such as a directed edge between knowledge category B and knowledge category D. Specifically, for the identification relationship, the node that the arrow moves away from corresponds to the knowledge category to which the user's question is identified, and the node that the arrow points to corresponds to the actual knowledge category to which the user's question belongs. For the transition relationship, the node that the arrow moves away from corresponds to the knowledge category corresponding to the customer service representative who received the user's question earlier, and the node that the arrow points to corresponds to the knowledge category corresponding to the customer service representative who received the user's question later. In some embodiments, the edges can also have attribute values, such as the probability value that the user's question is identified as a corresponding knowledge category in the identification relationship. As an example, the recognition relationship between knowledge category B and knowledge category D can have a probability value of 0.4, which means that the user's question is recognized as belonging to knowledge category B with a probability value of 0.4, while the user's question actually belongs to knowledge category D.

[0034] Step 230: Perform graph embedding processing on the graph to obtain the node vectors corresponding to the knowledge categories. In some embodiments, step 230 can be implemented by the embedding module 730.

[0035] Graph embedding aims to represent graphs using low-dimensional vectors. Through graph embedding, vector representations of each node in the graph can be obtained, leading to node vectors corresponding to each knowledge category. In some embodiments, nodes in the graph can be encoded to obtain initial vector representations with higher dimensions, such as 128 or 256 dimensions. Encoding methods can include one-hot encoding. In some embodiments, an initial vector representation can also be randomly generated for each node in the graph. Graph embedding maps graph nodes from their original high-dimensional space to a lower-dimensional (e.g., 64 or 32 dimensions) vector space, ensuring that nodes with edges have shorter distances between their corresponding vectors in the lower-dimensional vector space. Exemplary graph embedding methods include node2vec, LLE (Locally Linear Embedding), Laplacian Eigenmaps, GCN (Graph Convolutional Networks), VGAE (Variational Graph Auto-encoders), and others. It should be noted that the foregoing examples of graph embedding methods should not be taken as limitations on graph embedding processing in some embodiments of this specification; any method that can obtain vector representations of graph nodes can be applied here.

[0036] Step 240: Perform hierarchical clustering of knowledge categories based on node vectors to obtain a tree structure that reflects the hierarchical aggregation process of knowledge categories. In some embodiments, step 240 can be implemented based on aggregation module 740.

[0037] Hierarchical clustering creates a tree structure that reflects the aggregation process of knowledge categories by calculating the similarity of knowledge categories. Figure 5 This is a schematic diagram of a tree structure obtained through hierarchical clustering, as shown in some embodiments of this specification. The small circles in the diagram correspond to a knowledge category, and the connecting lines represent aggregation. Specifically, in the first layer of clustering, each knowledge category can be considered as a separate cluster. The similarity between any two clusters is calculated (e.g., the distance between the vector nodes corresponding to two knowledge categories is calculated; the shorter the distance, the greater the similarity). The two clusters with the highest similarity or a similarity greater than a set threshold are merged. Figure 5The diagram shows the first layer of clustering from bottom to top. It's clear from the diagram that after the first layer, the number of clusters decreases, and the number of knowledge categories in some clusters increases from 1 to 2. The second layer of clustering follows a similar approach. If the number of knowledge categories in a cluster is greater than 1, the knowledge categories from two clusters are paired, the distance between the node vectors in each pair is calculated, and the similarity between the two clusters is determined based on the maximum (or minimum, or average) distance across all pairs. After the second layer, the number of clusters further decreases, and the number of knowledge categories in some clusters becomes 3 or 4. This process continues until all knowledge categories are aggregated into a single large cluster.

[0038] Step 250: The clusters corresponding to two or more tree branches in the tree structure are each treated as independent knowledge category packages. In some embodiments, step 250 can be implemented by the sub-package module 750.

[0039] See also Figure 5 In some embodiments, clusters 510, 520, 530, and 540 can be treated as independent knowledge category packages. Thus, the knowledge categories obtained in step 210 are divided into four knowledge category packages.

[0040] In some other embodiments, the tree structure can be split from top to bottom. Still using... Figure 5 For example, we can start splitting from the root of the tree structure (i.e., the top-level aggregation line) to obtain cluster 510 corresponding to the left branch and clusters (the set of clusters 520 to 540) corresponding to the right branch. We then examine the left and right clusters to determine if they satisfy preset constraints. Clusters that satisfy the preset constraints are treated as independent knowledge category packages, while those that do not satisfy the constraints are further split. If cluster 510 satisfies the constraints, it is treated as an independent knowledge category package. If the clusters corresponding to the right branch (the set of clusters 520 to 540) do not satisfy the constraints, we continue splitting downwards to obtain cluster 520 corresponding to the left branch and clusters (the set of clusters 530 and 540) corresponding to the right branch. If cluster 520 does not meet the constraints at this point, it is further split downwards to obtain cluster 521 corresponding to the left branch and cluster 522 corresponding to the right branch. If both cluster 521 and cluster 522 meet the constraints, then two independent knowledge category packages can be obtained respectively. The set of clusters 530 and 540 can be processed in the same way. If they meet the preset constraints, they are treated as an independent knowledge category package; otherwise, the splitting continues downwards until the obtained clusters meet the preset constraints, thus obtaining the corresponding knowledge category packages.

[0041] In some embodiments, the preset constraints can be determined based on actual business needs. For online customer service, familiarity with the relevant knowledge in the corresponding knowledge category package is necessary to provide accurate knowledge points for user questions. The more knowledge a knowledge category package involves, the more time the corresponding customer service representative needs to spend learning this knowledge. For human customer service representatives, the required learning time is greater; for intelligent customer service representatives, the number of samples needed to train the corresponding customer service machine learning model is greater, naturally increasing the time required. Therefore, in some embodiments, the preset constraints include that the amount of knowledge involved in the cluster does not exceed a set value. Specifically, the amount of knowledge can be represented by the length or number of words in the relevant text, or by the number of relevant training samples. As an example, the aforementioned set value could be 10,000 words, 10 pages, 100,000 training samples, etc. In other embodiments, the preset constraints include that the customer service training time corresponding to the knowledge involved in the cluster does not exceed a set duration. As an example, the set duration could be 10 hours, 3 working days, etc.

[0042] In some embodiments, the text length or word count of the knowledge involved in the cluster, or the number of related training samples, can be counted. If the count exceeds a set value, the cluster is considered not to meet the preset constraints. In other embodiments, a learning time can be set for the corresponding knowledge. By accumulating the learning times of all knowledge involved in the cluster, the customer service training time corresponding to the knowledge involved in the cluster is obtained. When the customer service training time does not exceed the set time, the cluster is determined to meet the preset constraints.

[0043] The knowledge category packaging method provided in Process 200 obtains a tree structure reflecting the clustering process through hierarchical clustering, providing an explanatory basis for knowledge category packaging. The knowledge category node vectors used for clustering contain common relationships, identification relationships, and transition relationships between knowledge categories. When clustering knowledge categories based on such node vector distances, knowledge categories with common relationships, identification relationships, and transition relationships can be aggregated into the same knowledge category package, which helps improve customer service efficiency. Setting constraints based on knowledge volume or learning time to determine whether a cluster can be packaged independently can ensure that the knowledge category package has a high degree of knowledge cohesion, thereby saving customer service learning costs and further improving customer service work efficiency.

[0044] As mentioned earlier, knowledge categories can be divided according to the inherent logic of knowledge. Therefore, in some embodiments, knowledge categories can have a knowledge system that reflects their logical relationships. Figure 6 This is a schematic diagram of the knowledge system illustrated by some embodiments of this specification. Figure 6The diagram illustrates the knowledge system division for the concept of "account management." "Account management," "basic information," etc., can be viewed as knowledge categories, or as knowledge concepts at different levels. For example, "account management" belongs to the first-level knowledge concept 610. "Account management" can be further divided into "basic information" and "transaction records" within the second-level knowledge concept 620. "Basic information" can be further subdivided into "account type," etc., within the third-level knowledge concept 630. "Transaction records" can be further subdivided into "transaction time," "transaction amount," etc. It can be considered that the knowledge system information of knowledge categories is mainly divided based on the inherent logic of knowledge. While it differs from the knowledge package obtained in process 200 in its division method, there is a certain connection. For example, grouping knowledge categories under the same knowledge concept into the same knowledge package helps reduce the learning cost for customer service staff.

[0045] Therefore, in some embodiments, process 200 may further include an adjustment step, specifically including: obtaining knowledge system information of knowledge categories; determining the distribution ratio of knowledge categories belonging to the same knowledge concept in two or more knowledge category packages; and migrating knowledge categories with a distribution ratio less than a third threshold from their respective knowledge category packages to knowledge category packages with a distribution ratio not less than a fourth threshold, wherein the third threshold is less than or equal to the fourth threshold. For example, the third threshold may be set to 10%, and the fourth threshold may be set to 50%. For instance, according to steps 210-250, "transaction time," "transaction amount," and "transaction location" are aggregated in cluster (knowledge category package) 510, and "transaction method" is aggregated in cluster 521 (knowledge category package), while "transaction method," "transaction time," "transaction amount," and "transaction location" belong to the knowledge category under the knowledge concept "transaction record." Therefore, it can be calculated that the distribution ratio of knowledge categories under the knowledge concept "transaction record" in knowledge category package 510 is 75% (3 / 4), and the distribution ratio in knowledge category package 521 is 25% (1 / 4). Therefore, "transaction method" can be migrated from knowledge category package 521 to knowledge category package 510. In some embodiments, the adjustment step can be implemented by adjustment module 760.

[0046] In some embodiments, process 200 only packages the head categories in the knowledge category set. To complete the packaging of all knowledge categories, the remaining long-tail categories also need to be divided. In some embodiments, the long-tail categories can be divided into corresponding knowledge category packages based on the packaging of the head categories. The step of packaging long-tail categories can be implemented by the packaging module 750.

[0047] Similarly, long-tail categories can be subdivided using knowledge system information from knowledge categories. Specifically, the distribution ratio of head categories belonging to the same knowledge concept within the knowledge system as long-tail categories in one or more knowledge category packages can be determined; based on this distribution ratio, the long-tail category is assigned to the corresponding knowledge category package. For example, "transaction method," "transaction time," "transaction amount," and "transaction location" belong to the knowledge category "transaction record," where "transaction method" is a long-tail category, and "transaction time," "transaction amount," and "transaction location" are head categories. According to process 200, "transaction time" and "transaction amount" are assigned to knowledge category package 521, and "transaction location" is assigned to knowledge category package 522. It can be determined that the distribution ratio of head categories under the same knowledge concept "transaction record" in knowledge category package 521 is 67% (2 / 3), and the distribution ratio in knowledge category package 522 is 33% (1 / 3). Then, the long-tail category "transaction method" can be assigned to the knowledge category package 521 where the corresponding head category has a high degree of clustering. In some embodiments, the long-tail category can be assigned to the knowledge category package where the head category has a distribution ratio of not less than a fifth threshold. As an example, the fifth threshold can be 50%, etc. Based on this, "transaction method" can be assigned to the knowledge category package 521 where the distribution ratio is higher than 50% of the fifth threshold.

[0048] In some embodiments, due to threshold settings or other reasons, certain knowledge categories may not be automatically classified into specific knowledge category packages. As a fallback, knowledge categories that cannot be packaged can be grouped into one category, and then manually assigned to the knowledge category packages automatically divided by process 200.

[0049] As mentioned earlier, each knowledge category package corresponds to a certain amount of knowledge that customer service representatives need to learn. In some embodiments, additional training knowledge can be determined for process 200 to obtain the knowledge category package. This additional training knowledge represents the knowledge that the corresponding customer service representative needs to learn separately. When the customer service representative corresponding to a specific knowledge category package has a relatively large knowledge reserve, the probability of user questions being transferred can be further reduced, or it can be ensured that the user can obtain satisfactory knowledge points in one go. Specifically, the similarity between knowledge categories can be determined based on node vectors; for example, the shorter the vector distance, the more similar the corresponding knowledge categories. Based on the similarity between knowledge categories, one or more related knowledge categories outside the package can be determined for the knowledge category package in order to determine additional training knowledge for that knowledge category package. Taking knowledge category package 521 as an example, it involves transaction-related knowledge, including knowledge categories such as "transaction time," "transaction method," and "transaction amount." After similarity calculation, it was found that "account type" has a high similarity or relevance (e.g., up to 65%) with these knowledge categories, while its similarity with knowledge categories in other packages is low (e.g., none exceeding 40%). Therefore, "account type" can be identified as an external related knowledge category for knowledge category package 521. Furthermore, the knowledge corresponding to "account type" can be considered as additional training knowledge that customer service representatives corresponding to knowledge category package 521 need to learn. In some embodiments, the steps of determining external related knowledge categories and additional training knowledge for a knowledge category package can be implemented by the additional training knowledge determination module 770.

[0050] Figure 7 This is a schematic block diagram of a knowledge category classification system based on some embodiments of this specification. For example... Figure 7 As shown, system 700 may include an acquisition module 710, a mapping module 720, an embedding module 730, an aggregation module 740, and a sub-packaging module 750. Among them,

[0051] The acquisition module 710 is used to acquire two or more knowledge categories.

[0052] The graph construction module 720 is used to construct a graph with knowledge categories as nodes and the relationships between knowledge categories as edges.

[0053] The embedding module 730 is used to perform graph embedding processing on the graph to obtain the node vectors corresponding to the knowledge categories.

[0054] The aggregation module 740 is used to perform hierarchical clustering of knowledge categories based on node vectors to obtain a tree structure that reflects the hierarchical aggregation process of knowledge categories.

[0055] The sub-package module 750 is used to treat the clusters corresponding to two or more tree branches in the tree structure as independent knowledge category packages.

[0056] In some alternative embodiments, system 700 may further include adjustment module 760 and augmentation knowledge determination module 770.

[0057] The adjustment module 760 is used to: acquire knowledge system information of knowledge categories; determine the distribution ratio of knowledge categories belonging to the same knowledge concept in two or more knowledge category packages; and migrate knowledge categories with a distribution ratio less than a third threshold from their respective knowledge category packages to the knowledge category packages where the distribution ratio is not less than a fourth threshold, wherein the third threshold is less than or equal to the fourth threshold.

[0058] The knowledge enhancement determination module 770 is used to: determine the similarity between knowledge categories based on node vectors; and determine one or more external knowledge categories for a knowledge category package based on the similarity between knowledge categories, so as to serve as additional training knowledge for the customer service corresponding to that knowledge category package.

[0059] For more information on each module, please refer to [link / reference]. Figure 2 The relevant explanations will not be repeated here. It should be understood that... Figure 7 The systems and modules shown can be implemented in various ways. For example, in some embodiments, the systems and modules can be implemented by hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the methods and systems described above can be implemented using computer-executable instructions and / or included in processor control code, for example, on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The systems and modules of this specification can be implemented not only by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., but also by software, for example, executed by various types of processors, or by a combination of the aforementioned hardware circuits and software (e.g., firmware).

[0060] It should be noted that the above description of the system and its modules is for convenience only and should not be construed as limiting this specification to the embodiments described. It is understood that those skilled in the art, after understanding the principles of the system, may arbitrarily combine the modules, or construct subsystems connected to other modules, without departing from these principles. Alternatively, some modules may be split to obtain more modules or multiple units under a single module. Such modifications are all within the scope of this specification.

[0061] The beneficial effects that the embodiments of this specification may bring include, but are not limited to: (1) a tree structure reflecting the clustering process is obtained through hierarchical clustering, which provides an explanation basis for knowledge category sub-packaging; (2) the knowledge category node vector used for clustering contains the common relationship, identification relationship and transfer relationship between knowledge categories. When clustering knowledge categories based on such node vector distance, it can facilitate the aggregation of knowledge categories with common relationship, identification or transfer relationship into the same knowledge category package, which helps to improve customer service efficiency; (3) setting constraints on whether clusters can be packaged independently based on knowledge amount or learning time can ensure that the knowledge category package has a high degree of knowledge cohesion, thereby saving the learning cost of customer service and further improving the efficiency of customer service work.

[0062] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0063] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0064] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0065] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0066] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0067] For each patent, patent application, patent application publication, and other material, such as articles, books, specifications, publications, and documents, referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0068] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A method for subcontracting knowledge categories, comprising: Obtain two or more knowledge categories; Construct a graph using knowledge categories as nodes and the relationships between knowledge categories as edges; The graph is subjected to graph embedding processing to obtain the node vectors corresponding to the knowledge categories; Hierarchical clustering of knowledge categories based on node vectors yields a tree structure reflecting the hierarchical aggregation process of knowledge categories. This hierarchical clustering includes: Each knowledge category is treated as a separate cluster, and the distance between the node vectors corresponding to each pair of knowledge categories is calculated as the similarity between the two clusters. Iteratively merge two clusters with the highest similarity or with a similarity greater than a set threshold; Until all knowledge categories are aggregated into a large cluster, forming the tree-like structure; Each cluster corresponding to two or more tree branches in the tree structure is treated as an independent knowledge category package.

2. The method as described in claim 1, wherein the association relationship includes one or more of the following: being jointly hit by user questions, identifying a relationship, or being involved in user questions handled sequentially by two or more customer service representatives; wherein, The identification relationship exists between the knowledge category identified by the user's question and the actual knowledge category involved.

3. The method as described in claim 1, wherein the step of treating the clusters corresponding to two or more tree branches in the tree structure as independent knowledge category packages includes: The tree structure is split from top to bottom to obtain the clusters corresponding to the left branch and the clusters corresponding to the right branch; Clusters that meet the preset constraints are treated as independent knowledge category packages; The tree branches corresponding to clusters that do not meet the preset constraints are further split from top to bottom until the resulting clusters meet the preset constraints, thus obtaining the corresponding knowledge category package.

4. The method as described in claim 3, wherein the preset constraints include the amount of knowledge involved in the cluster not exceeding a set value or the customer service training time corresponding to the knowledge involved in the cluster not exceeding a set duration.

5. The method of claim 1, further comprising: Obtain knowledge system information for knowledge categories; Determine the distribution ratio of knowledge categories belonging to the same knowledge concept within two or more knowledge category packages; Knowledge categories with a distribution ratio less than the third threshold are migrated from their respective knowledge category packages to the knowledge category packages containing knowledge categories with a distribution ratio not less than the fourth threshold, where the third threshold is less than or equal to the fourth threshold.

6. The method as described in claim 1, wherein the two or more knowledge categories belong to the head categories in the knowledge category set; the head categories are a subset of knowledge categories in the knowledge category set whose percentage of hits by user questions is greater than a first threshold and whose percentage of category count is less than a second threshold.

7. The method as described in claim 1 or 6, wherein the two or more knowledge categories are obtained from one or more of the following knowledge categories: Two or more knowledge categories that are commonly hit by user questions, the knowledge categories that are identified in user questions and the knowledge categories they actually involve, and the knowledge categories involved in user questions that are handled sequentially by two or more customer service representatives.

8. The method of claim 6 further includes targeting long-tail categories in the knowledge category set, wherein the long-tail categories are knowledge categories in the knowledge category set other than the head categories: Obtain knowledge system information for knowledge categories; Determine the distribution ratio of head categories under the same knowledge concept in the knowledge system to which the long-tail category belongs, within more than one knowledge category package; Based on the distribution ratio, the long-tail category is divided into the corresponding knowledge category package.

9. The method of claim 8, wherein dividing the long-tail category into the corresponding knowledge category package based on the distribution ratio includes: The long-tail category is assigned to the knowledge category package containing the head category whose distribution ratio is not less than the fifth threshold.

10. The method of claim 1, further comprising: Similarity between knowledge categories is determined based on node vectors; Based on the similarity between knowledge categories, identify one or more related knowledge categories outside the knowledge category package in order to determine additional training knowledge for that knowledge category package.

11. A knowledge category subcontracting system, comprising: The acquisition module is used to acquire two or more knowledge categories; The graph construction module is used to construct a graph with knowledge categories as nodes and the relationships between knowledge categories as edges; An embedding module is used to perform graph embedding processing on the graph to obtain node vectors corresponding to knowledge categories; The aggregation module is used to perform hierarchical clustering of knowledge categories based on node vectors, obtaining a tree structure that reflects the hierarchical aggregation process of knowledge categories. The hierarchical clustering includes: Each knowledge category is treated as a separate cluster, and the distance between the node vectors corresponding to each pair of knowledge categories is calculated as the similarity between the two clusters. Iteratively merge two clusters with the highest similarity or with a similarity greater than a set threshold; Until all knowledge categories are aggregated into a large cluster, forming the tree-like structure; The sub-package module is used to treat the clusters corresponding to two or more tree branches in the tree structure as independent knowledge category packages.

12. The system of claim 11, wherein the association relationship includes one or more of the following: user questions that are jointly hit, relationship identification, or user questions that are sequentially handled by two or more customer service representatives; wherein, The identification relationship exists between the knowledge category identified by the user's question and the actual knowledge category involved.

13. The system of claim 11, wherein the sub-packaging module is further configured to: The tree structure is split from top to bottom to obtain the clusters corresponding to the left branch and the clusters corresponding to the right branch; Clusters that meet the preset constraints are treated as independent knowledge category packages; The tree branches corresponding to clusters that do not meet the preset constraints are further split from top to bottom until the resulting clusters meet the preset constraints, thus obtaining the corresponding knowledge category package.

14. The system as described in claim 13, wherein the preset constraints include the amount of knowledge involved in the cluster not exceeding a set value or the customer service training time corresponding to the knowledge involved in the cluster not exceeding a set duration.

15. The system of claim 11, further comprising an adjustment module for: Obtain knowledge system information for knowledge categories; Determine the distribution ratio of knowledge categories belonging to the same knowledge concept within two or more knowledge category packages; Knowledge categories with a distribution ratio less than the third threshold will be migrated from their respective knowledge category packages to knowledge category packages containing knowledge categories with a distribution ratio not less than the fourth threshold. The third threshold is less than or equal to the fourth threshold.

16. The system as described in claim 11, wherein the two or more knowledge categories belong to the head categories in the knowledge category set; the head categories are a subset of knowledge categories in the knowledge category set whose percentage of hits by user questions is greater than a first threshold and whose percentage of category count is less than a second threshold.

17. The system of claim 11 or 16, wherein the two or more knowledge categories are obtained from one or more of the following knowledge categories: Two or more knowledge categories that are commonly hit by user questions, the knowledge categories that are identified in user questions and the knowledge categories they actually involve, and the knowledge categories involved in user questions that are handled sequentially by two or more customer service representatives.

18. The system of claim 16, wherein the sub-package module is further configured to, for long-tail categories in the knowledge category set, the long-tail categories being knowledge categories in the knowledge category set other than the head categories: Obtain knowledge system information for knowledge categories; Determine the distribution ratio of head categories under the same knowledge concept in the knowledge system to which the long-tail category belongs, within more than one knowledge category package; Based on the distribution ratio, the long-tail category is divided into the corresponding knowledge category package.

19. The system of claim 18, wherein the sub-packaging module is further configured to: The long-tail category is assigned to the knowledge category package containing the head category whose distribution ratio is not less than the fifth threshold.

20. The system of claim 11, further comprising a knowledge determination module, used for: Similarity between knowledge categories is determined based on node vectors; Based on the similarity between knowledge categories, identify one or more related knowledge categories outside the knowledge category package in order to determine additional training knowledge for that knowledge category package.

21. A knowledge category clustering apparatus, comprising a processor and a storage medium, the storage medium for storing computer instructions, the processor for processing at least a portion of the computer instructions to implement the method as described in any one of claims 1 to 10.

22. A storage medium storing computer instructions that, when at least a portion of the computer instructions is executed by a processor, implement the method as described in any one of claims 1 to 10.

Images