We present an interactive search assistance agent that integrates search and recommendation-based experiences into a novel unified presentation. The agent guides the user toward more desirable inventory, while also satisfying the constraints that the user constructs with the help of the agent. We built a prototype which supports this mechanism by connecting to the search functionality on eBay. We have also created the popularity knowledge-base of the agent by aggregating data from billions of user transactions. The accompanying video1 demonstrates the resulting prototype in this context.
Many popular applications that provide services like
shopping, search, media, and social networking, rely on
information retrieval (IR) technologies that can be broadly
categorized into two groups: Query-based systems that
primarily aim to satisfy user input (i.e. keyword search, filtering,
and browsing) [
Here, we present Focus, and interactive assistant for a shopping website, which blurs the lines between user querybased search and system-initiated recommendations. Our proposal involves an intelligent system that unifies keyword search, category browsing, attribute filtering, query completion, related query recommendation, and popularity-based recommendations.
Focus behaves similar to a search engine in that it returns results satisfying user queries and selected filters, while simultaneously acting like a recommendation engine in introducing popular inventory. It can assist users by suggesting refinements for narrowing a query and proposing changes to particular parts of a query in order to move the search towards alternative directions. The latter functionality allows the user to discover popular parts of inventory that contain products with high seller supply and buyer demand. This also helps the user avoid (or backtrack from) low result scenarios.
Our design observes several principles:
• Interactive: Shopping/search should be a conversational
interaction between the user and shopping assistant.
• Mixed-initiative [
Researchers often discuss personalization of search and recommendations in two distinct contexts: customization with respect to long term user models, and adaptation to short-term user actions. The mechanisms that we propose here belong to the latter category. However, we believe that this system would benefit from long-term user models as well, and so we pose that potential integration as an open question for future work.
We implemented a prototype of Focus and demonstrate its feasibility in the e-commerce domain. The system powers its recommendations with data aggregated from billions of transactions on eBay. Next, we go through a motivating example, followed by an overview of the runtime architecture and offline processes that build the system’s knowledge-base. 2
The paper is accompanied by a video demonstrating the user-interface interaction1. In preparing a demo system we were forced to make certain UI design choices, but the claims and architectural commitments we make in this paper are more abstract in nature and they should not be evaluated limited to this particular interface.
The user starts the interaction by typing an initial query to a search box, or by selecting a group of filters from the landing page of the experience. This landing page is currently hand-curated but a natural extension would be to construct it by determining popular clusters of items, or by personalizing it based on past experience of the user. Subsequently, the system will respond by showing relevant results for the selected set of filters and recommends potential changes to the query. After every user action, the system retrieves new results and updates its query recommendations. These recommendations are incremental, targeting only the specific user selected parts of the query.
At the heart of the communication between the user and the IR system is a user interface that represents the query, along with changes recommended by the system. This acts as shared knowledge between the user and the system, and helps to align their goals. This assisted search approach is similar to widely used autocomplete functionality in recommending changes to a query, but it differs in two key ways. First, the query is partitioned into named entities. Additionally, recommended changes are incremental and can target any selected segment of the query. This provides the user with multiple directions for changing the query in incremental fashion, resulting in a more interactive experience, which allows the user to navigate through the inventory efficiently.
The user interface (Figure 1) consists of three elements: search context (top two rows), which characterizes the current query for information retrieval, recommendations for changing the query (dark bar), which list the recommendations to lead the user towards popular parts of the inventory, and a result set consisting of items that best match the search context. The search context includes a keyword query and a set of selected filters consisting of attribute name-value pairs. The search context is constructed by user’s initiative but the recommender system helps by suggesting new refinements and possible changes to the existing query. Whenever the user changes the search context (either by direct editing or by selecting a system recommendation), the system updates the search results that match that new context.
For example when the user enters the query “coach shoulder bag,” the system recognizes the attributes brand=Coach, style=Shoulder Bag, and category=Clothing Shoes and Accessories by applying a named entity extraction mechanism, which resolves ambiguities by considering co-occurrence frequencies in historical transactions. Next, the system updates the interface with these filters and shows relevant results from the inventory. Using this information, the system also recommends new attribute filters such as color and shoe size since those are filters that work well with the selected filters (in terms of increasing the likelihood of retrieving desirable inventory). At this point, the user can click on one of these attributes (e.g. color) and get an ordered list of recommended values that work well with the previous set of filters (Figure 1). In this example, brown is at the top of that list because it is a popular color for coach shoulder bags.
The user can also select one of the existing filters and get alternative recommendations that work best with the current search context (Figure 2). For a given selected filter, the values are recommendations that lead the user towards popular parts of the inventory. Those recommendations are determined dynamically based on past popular user activity statistics, which we will describe in the next section. For example, clicking on brand filter might retrieve the value Vera Bradley as another popular brand, which also correlates with shoulder bags. Similarly, clicking on style would trigger recommendations for popular item styles for Coach, including totes and messengers.
Finally, the user can continue typing new keyword queries. During this process, the system may suggest autocompleting the keyword (e.g. the partial query “bl” could trigger the filter selection color=black). This autocomplete mechanism also prefers entries that work best with the current search context, among the ones that match the partial query. 3
Focus architecture is partitioned into data storage, runtime system, and offline data generation (Figure 3). Next, we review these components and explain how they support the functionality described in the previous section. 3.1
The runtime system includes a number of services that respond to user actions. The interface state consists of search context, query change recommendations, and search results. The user actions change the search context and the runtime performance system responds by changing the result set and recommendations.
The runtime performance system consists of three main components. First, the item retrieval system returns a set of items from the inventory that best match the search context. Second, the attribute extraction service extracts a number of attribute-value pairs from a keyword query. Finally, the third service recommends changes on the query given the search context. In this work, we are focusing only on the third component that generates the recommendations and therefore we will not describe the remaining components in more detail.
The query recommendations component consists of a number of services, which all utilize the same backend data storage and inference engine. The structured autocomplete service inputs the search context along with a partial keyword query, and returns filter values that match the partial keyword query, preferring popular filters that co-occur with selected filters in the search context in past transactions. The attribute name refinement service returns most popular attribute names to be used for further filtering given selected filters. Finally, the attribute value selection service return best values for a chosen filter given the selected filters in the search context. All of these services use the same backend engine that stores information about popularity of attributes and their interaction. 3.2
All query recommendation services rely on the backend reasoning engine. Each service uses this engine to retrieve candidate values and order them based on a single popularity metric. We will first describe this popularity metric and then we will discuss the retrieval process specific to each service.
Inventory Clickstream
Data Structured Data Attribute
Relevance The Data Store
Refinement Alternatives Autocomplete
Our goal is to estimate the conditional probability P(y | x) representing the likelihood of the user finding desired items in the result set, when filtering by a name-value pair y, given the selected name-value filters x = x1, x2… xn. For example, given the selected filter vector x=<brand=nike, type=shoe>, candidates for y may include constraints like color=white or size=10. In that case, the recommendation engine would need to determine whether color=white or size=10 is a better refinement. The algorithm merely sorts candidate instantiations for y by maximizing P(y | x) for a given x. We achieve this by Naïve Bayesian inference, where we have:
P(y | x) ~ P(x 1| y) P(x 2| y)… P(x n| y) P(y) assuming conditional independence:
P(x i x j| y) = P(x i| y) P(x j| y) Under that assumption, the order of P(y | x) for a fixed x depends only on P(xi| y) and P(y) values.
The three recommendation services use the backend engine differently, depending on how they select candidate values of y. For efficient retrieval, all values are stored in a table which has one row for each y instance and has columns observing the following schema:
<name(y), value(y), P(y), P(x 1| y), P(x 2| y),… , P(x n| y)> This table has O(n) columns and rows, where n is the number of attribute-value pairs and in our domain. Moreover, we assume that the matrix is sparsely populated, which is an assumption that holds in our shopping domain.
The typical goal is to return y names and/or values (the first two columns), given the probability values. For a set of selected context filters x =<x1,x2,..xn>, all services retrieve only y rows such that:
P(x1| y) ≠ 0, P(x2| y) ≠ 0,…, P(xn| y) ≠ 0
Given a sparse matrix, this significantly reduces the number of candidates and their retrieval becomes very efficient with usual indexing.
On top of the shared retrieval constraints above, the suggestion services use additional constraints. In structured autocomplete with the partial keyword query q, the system enforces the additional constraint contains(name(y), q), e.g.
Item retrieval
Recommended items
User
Interface Query recommendations query, selected filters the query “re” retrieves only aspects like color=red, where the query is contained in the aspect value. On the other hand, in attribute value refinement, the name N of the attribute is given as input, we use the additional constraint name(y) = N, e.g. when the filter color is selected, all retrieved y rows satisfy name(y)=“color”. The attribute name recommendations are handled with a slight extension where y represents only the attribute name (without value). This fits in our database with minor changes. 3.3
The mechanism we defined in the previous section defines a conditional probability metric P(xi| y), which we defined as the probability of selection of y (filter name or name-value pair) to be useful for the user, given a selected attribute filter xi, and P(y) the unconditional probability of selection of the filter y to be useful. However, we have not described how we can obtain those values in a practical use case.
If we have a system running in production, those values can be obtained based on usage of filters and the engagement with their results. However, it is not clear how we should initialize such a system. In the shopping domain, there are several alternatives that can be used as proxies to these probabilities, each resulting in different runtime behavior. One can use data from engagement with an existing (but static) filter system, or use inventory-based metrics (i.e. how many items in inventory satisfy brand=nike and category=basketball shoes at a given time). Instead, we decided to optimize our system for popularity. Hence, we calculate the P values by listing item view actions and counting cooccurrence of attribute-value pairs (e.g. number of viewed items with attributes brand=nike and color=white). Consequently, the resulting system is biased towards preferring items with higher rates of user interaction. 4
Our results are quite preliminary, and we have not yet conducted a systematic user experiment. We implemented a prototype user interface (demonstrated in the accompanying video) powered by real user activity data. While this kind of interface could be useful for different computing environments, its strength is highlighted in touch screen devices, where selecting from suggestions is easier than typing, and there is limited space for suggestions.
The backend data is automatically generated using
billions of items viewed at eBay and it covers a large portion
of items in the inventory that contain attribute data. Our
item retrieval service and concept extractor utilizes existing
services at eBay. We built the query recommendation
services from scratch and they utilize a Solr [
A related approach that is recently gaining importance is
conversational search like "Google Now," "Apple Siri," and
“Microsoft Cortana,” [
We presented an information retrieval experience for a shopping domain that merges search and recommendations in a novel way. The system facilitates an incremental mixed-initiative interaction between the user and a recommender agent, which leads the user towards popular parts of the inventory, while also satisfying user queries. We implemented a functioning prototype that utilizes data mined from billions of transactions on eBay and the backend algorithm is efficient and scalable.
We are at early stages of this work and lack crucial evaluation demonstrating the utility of this system. However, we believe that our contribution is a novel step towards more intelligent interactive information retrieval systems and can encourage future research in this area.