Patent Application
20160140130
The present disclosure relates generally to information search and retrieval technologies and, more particularly, to technologies for implicit collaborative searching based on a search history database.
Customer support agents typically relay on a knowledgebase to provide solutions to technical support problems. However, knowledgebases frequently contain gaps in knowledge and do not provide an answer to every technical support problem. When a solution to a technical support problem is not found in the knowledgebase, customer support agents may conduct searches on the Internet to find a solution.
Discovering solutions to technical support problems on the Internet can be time consuming. Most Internet search engines are not designed to surface solutions to technical support problems. Rather, rankings are usually based on the linking structure of web pages, which does not necessarily surface the most relevant results. Therefore, agents must spend a lot of time reviewing and filtering the search results to find web pages that provide a solution to a particular technical support problem. The efforts of one technical support agent may subsequently duplicated by another technical support agent that is presented with the same technical support problem.
The present disclosure relates to collaborative search techniques that enable customer support agents to quickly find solutions to technical support problems and to recommend web pages providing solutions to technical support problems to other persons in the technical support community. The present disclosure also provides insight to knowledgebase managers on gaps in the knowledge base and new content to fill the gaps. The main elements of the collaborative search system comprise a client-side utility that installs into a web browser used by a technical support agent, a database server that stores a history of searches conducted by customer support agents, and an analytics engine to analyze searches conducted by customer support agents.
The browser utility is an application that installs as a browser extension. The browser utility captures search information as customer support agents perform Internet searches. The captured information includes search queries entered by the technical support agent, clicks on search results, and timestamps for search queries and clicks. In addition, the browser utility adds a button on the toolbar of the browser that allows agents to recommend any web pages that the agent finds helpful in finding a solution to a technical support problem. All data collected by the browser utility is sent in real time to the database server.
The database server maintains a search history database that stores the search queries performed by customer support agents along with web pages recommended by the customer support agents. When a technical support agent performs a search, the browser utility sends the search query to the database server. The database server compares the received search query to searches stored in the search history database. If the search history database contains a previous search that is sufficiently similar to the current search query, the database server outputs recommended web pages associated with the matching search queries to the browser utility. The browser utility then displays the recommended web pages to the agent in the browser window along with the conventional search results.
The analytics service provides analytics for web searches conducted by the customer support agents. Information provided by the analytics service includes usage trends (e.g., aggregate number of searches performed per day), average search time, query trends (e.g., aggregate statistics for most frequent searches); most visited web sites, and list of suggested or recommended web pages with corresponding search queries. The list of recommended web pages is derived from web pages flagged by customer support agents.
According to another aspect of the disclosure, a technique is provided of expanding a search query entered by a customer support agent that fails to fully specify the information need. Where the information need is not fully specified, the keywords entered by the customer support agent may be compared to a predefined set of query patterns. These query patterns comprises components that correspond to different ontological classes. If the search query fails to fully describe the information need, the query expansion function may identify a set of candidate patterns based the keywords in the search query and prompt the user to either enter additional keywords corresponding to the class of the missing component or to select from a set of candidate queries that more fully describe the information need.
According to another aspect of the disclosure, a technique is provided of naming a query cluster. Queries in the search history database representing the same information need may be grouped into query clusters. Using a domain ontology, a set of templates may be defined that describe the typical patterns followed by search queries. Each pattern comprises a set of components that correspond to the classes defined by the domain ontology. The templates may be pre-defined by a knowledge base manager or machine generated. Cluster names are generated by mapping the most relevant keywords in a query cluster to corresponding components in a selected one of the naming templates.
Referring now to the drawings, a collaborative search system 10 according exemplary embodiment is shown. The collaborative search system 10 is designed to complement technical support knowledgebases that may be used by customer support agents. However, knowledgebases frequently contain gaps in knowledge and do not provide an answer to every technical support problem. When a solution to a technical support problem is not found in the knowledgebase, customer support agents may conduct searches on the Internet to find a solution. The collaborative search system 10 enables customer support agents to more quickly find solutions to technical support problems and to recommend web pages providing solutions to those technical support problems to other persons in the technical support community. The collaborative search system 10 also collects information providing insight to knowledge base managers regarding gaps in a technical support knowledgebase.
Referring to
The browser utility 15 is an application that installs as a browser extension. The browser utility 15 captures search information and browsing history as customer support agents perform web searches and browse the web for solutions to technical support problems. The captured information includes search queries entered by the technical support agent, clicks on search results, timestamps for queries and clicks, and dwell times. In addition, the browser utility 15 adds a button 52 on the tool bar of the browser window that allows technical support personnel to “flag” any web pages that the technical support person finds helpful in finding a solution to a technical support problem. All data collected by the browser utility 15 is sent in real time to the database server 20.
The database server 20 maintains a search history database 25 that stores the search queries performed by customer support agents, browsing information, and addresses of recommended web pages. When a technical support agent performs a search, the browser utility 15 sends the search query to the database server 20. The database server 20 compares the received search query to previously performed searches stored in the search history database 25. If the search history database 25 contains a previous search query that is similar to the current search query entered by the technical support agent, the database server 20 outputs the web address (e.g. URL) any recommended web pages associated with the similar search query to the browser utility 15. If multiple search queries stored in the search history database 25 match the current search query, the addresses of the recommended pages associated with all or selected ones of the similar search queries may be output. The browser utility 15 then generates a search results page that lists or highlights the recommended web pages along with the conventional search results supplied by the web search engine.
The analytics service 30 provides analytics for the searching and browsing information stored in the search history database 25. The analytics service 30 may provide information such as usage trends (e.g., aggregate number of searches performed per day), average search time, query trends (e.g., aggregate statistics for most frequent searches); most visited websites, and a list of suggested or recommended web pages with corresponding search queries. The list of recommended web pages is derived from web pages flagged by customer support agents.
The database server 20 timestamps the search query and stores the search query and timestamp in the search history database (step 6). The database server 20 compares the current search query entered by the technical support agent to previously performed search queries stored in the search history database 25 and generates a list of recommended pages (step 7). The recommended pages comprise web pages previously “flagged” or recommended by other customer support agents using the collaborative search system 10. The recommended web pages may be identified, for example, by a uniform resource locator (URL), IP address, or other identifer. The database server 20 then returns the list of recommended pages to the browser utility 15 (step 8). Upon receipt of the recommendations from the database server 20, the browser utility 15 generates and displays an enhanced search results page including the search results returned by the search engine 25 (step 9). The enhanced search results page also lists or highlights the recommended pages returned by the database server.
Referring back to
The browser utility 15 installs a recommend button 52 that is displayed on the menu bar of the browser window 50. See,
In some embodiments, the browser utility 15 may display a dialog box for entering the user's name when the recommend button 52 is clicked. See,
In one embodiment, query clusters are used to simplify the search for similar queries in the search history database. There are many known techniques for clustering queries and the particular clustering technique used is not a material aspect of the invention. In general, a query cluster is formed by a group of similar search queries representing the same or similar information need. Once the query clusters are formed. the current search query can be compared to the query clusters rather than to individual search queries stored in the search history database to determine the set of previous search queries that are most similar to the current search query. However similarity is determined, the recommended URLs associated with the query cluster having the most similar results may be output to the browser utility 15.
In one exemplary embodiment, the collaborative search system uses hierarchical clustering technique (divisive or agglomerative) based on edge betweeness centrality for clustering queries. To briefly summarize, a high-connected graph is constructed based on information in the search history database. The graph includes four data node types: 1) query nodes; 2) result URL nodes; 3) clicked URL nodes; and 4) recommended URL nodes. The query nodes represent the search queries entered by the customer support agents. The result URL nodes represent the results returned by the search engine for a specific query. The clicked URL nodes represent the web pages visited by the customer support agent during a search. The recommended URL nodes represent the web pages that are recommended by the customer support agent. The query nodes are connected by edges to the corresponding result URL nodes, clicked URL nodes and recommended URL nodes. Assuming that all nodes are connected, the graph represents one data set comprising all searches.
In order to generate the query clusters, a divisive hierarchical technique may be used in which the graph representing the entire data set is recursively split into smaller data sets or clusters until a termination criteria is met. At each step, the clustering function selects a cluster, computes the edge betweeness centrality for all edges within the cluster, and removes the edge with the maximum betweeness centrality. This process is repeated for all clusters so formed until the clusters have no edges with a betweeness centrality greater than a threshold. Alternatively, an agglomerative hierarchical technique may be used to generate the query clusters in which the clustering function begins with a single node and builds a cluster until a termination criterion is met.
When a new search is performed, the search results returned by the web search engine 25 are provided to the database server 20. The database server compares the search results returned by the web search engine 25 with result URLs in each query cluster and determines the query cluster having the most results in common with the search results returned by the web search engine 25. The recommended URLs for the query cluster having the most similar results is output to the browser utility 15. The current search query is then assigned to the selected query cluster and stored in the search history database.
Distance-based clustering techniques based on keyword similarity may also be used to generate the query clusters. In one distance-based clustering technique, search queries are represented as points in a multidimensional space, where each axis of the multidimensional space represents a word or character. Similar search queries will be close in distance while dissimilar search queries will be far apart. The query clusters will appear as a cloud of points in close proximity. Query clusters are thus determined by computing the distance between search queries and grouping queries within a predetermined distance to each other, or to a common point.
Distance metrics, such as the well-known Levenschtein distance, may be used to determine the similarity or closeness of the search queries. The Levenschtein distance between two queries is the minimum number of single character edits, such as insertions, deletions or substitutions, required to convert one query to another. The Levenschtein distance belongs to a larger class of distance metrics known as edit distances. In one embodiment, queries that are determined to be within a predetermined distance from each other, or to a common point, using Levenschtein distances may be grouped to form a query cluster.
Each query cluster so formed can be represented by a centroid that is similar in form to the search queries within the query cluster. When a new search is performed, the current search query being executed is compared to the centroid of each query cluster. Levenschtein distance may also be used for determining the similarity between a current search query and the centroid of a query cluster. If the distance threshold is met, the database server 20 outputs the recommended web pages associated with any queries in the cluster. The current search query is then assigned to the query cluster and stored in the search history database. The centroid of the query cluster is then recomputed.
The first record in the record set shown in
The cluster table stores the cluster ID and the result URLs or centroid of each defined query cluster. Rather than search through the entire search history table to find similar queries, the database server 20 may be configured to compare the results returned by the current search query with the result URLs of each query cluster. Alternatively, the database server 20 may be configured to compare the keywords of the current search query with the centroid of each query cluster using, for example, a distance metric. If the search query is found to belong in a particular query cluster, the cluster ID is used to lookup recommended web pages in the recommendation table.
The recommendation table associates each recommendation with a cluster ID and stores the cluster ID and URL of the recommended webpage. The recommendation table may store multiple recommendations for each query cluster. If, during a search session, the technical support agent clicks on the recommend button 52 in the browser window 50, the database server 20 associates the recommended web page with a particular query cluster and stores the recommendation in the recommendation table. When a current search query is found to be similar to a particular query cluster, all recommendations associated with that query cluster will be included in the document list generated by the database server 20. Thus, all recommendations resulting from search queries belonging to the same query cluster will be included in the document list generated by the database server 20.
In one embodiment database server 20 connects via internal or external bus to the knowledge database and search history database and is responsible for maintaining both. In other embodiments, the knowledge database may be maintained by a separate database server accessible via the Internet.
Although the embodiments are described in the context of a technical support solution, those skilled in the art will appreciate that the techniques described herein may be used to facilitate collaborative searching by any group of users with a common information need.
According to another aspect of the disclosure, the data analysis server 30 may analyze the data to provide useful information to knowledge base managers such as usage trends (e.g., aggregate number of searches performed per day), average search time (e.g., average time of a search session), query trends (e.g., aggregate statistics for most frequent searches), and most visited websites (list of recommended web pages with corresponding search queries). The record of search queries within the search history database also reflects the information needs of the customer support agents. Gaps within the knowledge base, referred to herein as knowledge gaps, may be ascertained by analyzing the search history database to determine the information needs.
In order to facilitate knowledge gap analysis by knowledge base managers, it is useful to generate cluster names for query clusters that accurately represent the information need represented by the query cluster. The data analysis server 30 may automatically detect and label query clusters using a domain ontology and textual templates. The query cluster names generated using the domain ontology more accurately describe the information need in language that is readily understood by the knowledge base managers.
Search engines require that an information need be expressed as a set of keywords forming a search query. The term keyword as used herein refers to a single word or phrase that describes a concept. In the field of customer support or technical support, the search queries follow a limited set of patterns. These patterns may be defined in terms of an ontology representing the knowledge domain. The ontology comprises a number of different components which may be generally labeled as entities (or individuals), classes and relations. Entities are the base components of the ontology and represent the set of things that the ontology describes. Classes represent a group of entities that share common characteristics or attributes. Relations represent the way entities or classes relate to one another.
Using the domain ontology, a set of templates may be defined that describe the typical patterns followed by search queries. Each pattern comprises a set of components, shown in brackets, that corresponds to a class defined by the ontology. Table 2 below illustrates exemplary templates based on the technical support ontology shown in
As shown by the examples in
According to another aspect of the disclosure, patterns or templates defined based on the domain ontology may also be used for search query expansion. Frequently, search queries entered by customer support agents fail to fully describe the information need. Where the information need is not fully specified, the keywords entered by the customer support agent may be compared to a predefined set of query patterns. These query patterns, similar to the naming templates described above, comprises components that correspond to different ontological classes. If the search query fails to fully describe the information need, the query expansion function may identify a set of candidate patterns based the keywords in the search query and prompt the user to either enter additional keywords corresponding to the class of the missing component or to select from a set of candidate queries that more fully describe the information need.
For example, assume that the information needs represented by search queries fall into one of the following information need patterns shown in Table 3 below, which may be pre-defined by a knowledge base manager or machine generated.
If customer support agent enters the search query “Firefox for Windows 7 shows a blank page.” The search terms “Firefox”, “Windows 7” and “blank page” are recognized as entities in the classes Software, Platform and Anomaly respectively. The software selects candidate patterns that include components corresponding to these three classes. For the example query, the first query pattern in Table 3 is selected because it includes components corresponding to each of the three specified keywords. The candidate search pattern includes an additional component corresponding to the class Device. The original query does not specify an entity in the class Device. Therefore, query expansion is performed to generate a new query including the original three keywords and an additional keyword to specify a device. In one embodiment, the query expansion function prompts the user to enter a search term corresponding to the class Device. The prompt may, for example, read “Enter type of device.” In this case, the user inputs a keyword in the class Device to complete the query. In some cases, the user may be prompted to enter multiple keywords to complete the query. In another embodiment, query expansion function may present a list of suggested queries to the user where each suggested query includes the original search terms and an additional search term in the class Device. The list of suggested queries may, for example, be:
The suggested queries may be ranked according to frequency of usage or other criteria. The user then selects a query from the list of suggested queries.
The process 150 begins when the knowledge base manager or other user inputs a search query (block 155). The query expansion processor processes the query to determine whether it completely specifies the information need (block 160). If so, the query expansion processor forwards the search query to a search engine 35 to be performed (block 190). If not the process continues and the query expansion processor identifies a set of one or more candidate patterns matching the keywords and structure of the entered search query (block 165). For each candidate pattern, the query expansion processor determines components that are not specified by the search query and expands the search query with instances of the missing components (block 170). For example, if a component of the class Device is not specified in one of the patterns, the query expansion processor may expand the search query by adding keywords of the class Device to the original search query to generate a list of expanded search queries. The query expansion processor outputs the list of expanded search queries to the user and prompts the user to select a search query from the list ((block 175). In some embodiments, the query expansion processor may rank the search queries according to frequency of use, relevancy, or other criteria. The query expansion processor receives user input indicating a selection of an expanded search query (block 180). Upon receipt of the user selection, the query expansion processor forwards the selected search query to the search engine 35 (block 190).
