Supporting Product Selection with Query Editing
Recommendations
Derek Bridge
Department of Computer Science
University College Cork
Cork, Ireland
d.bridge@cs.ucc.ie
Francesco Ricci
Faculty of Computer Science
Free University of Bozen-Bolzano
Bozen-Bolzano, Italy
fricci@unibz.it
ABSTRACT
Consider a conversational product recommender system in
which a user repeatedly edits and resubmits a query until
she finds a product that she wants. We show how an advi-
sor can: observe the user’s actions; infer constraints on the
user’s utility function and add them to a user model; use
the constraints to deduce which queries the user is likely to
try next; and advise the user to avoid those that are unsat-
isfiable. We call this information recommendation. We give
a detailed formulation of information recommendation for
the case of products that are described by a set of Boolean
features. Our experimental results show that if the user is
given advice, the number of queries she needs to try before
finding the product of highest utility is greatly reduced. We
also show that an advisor that confines its advice to queries
that the user model predicts are likely to be tried next will
give shorter advice than one whose advice is unconstrained
by the user model.
Categories and Subject Descriptors
H.3.3 [Information Search and Retrieval]: Query for-
mulation
General Terms
Human Factors
Keywords
recommender systems, user models
1. INTRODUCTION
Recommender systems are intelligent e-commerce appli-
cations that suggest products or services which best suit a
user’s needs and preferences, in a given situation and con-
text [1, 2]. They have been successfully exploited for rec-
ommending travel services, books, CDs, financial services,
insurance plans, news, and in many other application mar-
kets. From a technical point of view, recommender systems
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
RecSys’07, October 19–20, 2007, Minneapolis, Minnesota, USA.
Copyright 2007 ACM 978-1-59593-730-8/07/0010 ...$5.00.
emerged as supervised learning approaches using a data set
of numerical ratings on products (e.g., from 1=bad to 5=ex-
cellent), expressed by a collection of users on a catalogue of
products, to make a prediction for products not yet rated
by the target user, i.e., the user for whom a recommenda-
tion is sought. Prediction algorithms include collaborative-
filtering, content-based filtering and case-based reasoning [1,
2, 3]. However, these classical approaches typically support
a simple human-computer interaction model, which basically
first collects user related information (ratings or product
preferences) and then exploits the background knowledge to
make ratings’ predictions and derive product recommenda-
tions.
More recently, a number of conversational approaches have
been proposed. In conversational recommender systems the
advisor not only suggests and ranks products, it also guides
the user by asking for more information about her prefer-
ences or providing information about the product and the
search process, e.g., explaining the rationale of the ranking
or explaining the failure of a search initiated by the user [8,
5, 3, 9, 10, 11, 7]. The user may not know, or may not be
aware, of all her preferences at the start of the interaction.
Preferences are revealed, or even constructed, during the in-
teraction as the product space is explored. By contrast, the
user of a non-conversational (‘single-shot’) recommender is
expected to be able to articulate all preferences up-front.
In this paper, we introduce the idea of information rec-
ommendation, bringing the concept of conversational recom-
mender systems to its more radical interpretation. A conver-
sational recommender can use information recommendation
to suggest actions that help the user to efficiently search
for products, as well as using product recommendation to
suggest products that the user may like.
Consider a conversational product recommender system in
which a user repeatedly edits and resubmits a query until she
finds a product that she wants [9, 5]. An advisor can infer
constraints on the user’s utility function by observing the
user’s actions. For instance, the system might infer that the
features constrained by the user query are more important,
for the user, than the features not yet used in the query.
The advisor can add these constraints to a particular kind
of dynamic user model [4, 8]. The advisor can then use
the constraints to deduce new preference relations between
product features and ultimately to rank the next possible
search actions of the user, rather than, or as well as, using
the preference relations to select and rank products in the
catalogue. In other words, in information recommendation,
the advisor uses the user model to determine the feasibility
65

of actions (the satisfiability of queries in this case) that it
thinks the user is more likely to try. It can then advise the
user of which to try or which to avoid.
In the rest of this section we compare the use that infor-
mation recommendation makes of its user model with the
use that product recommendation makes. In the Adaptive
Place Advisor, for example, the user model is used for prod-
uct selection [11]. The advisor infers feature weights and
defaults, and uses them in product retrieval. Similarly, in
the work of Pu et al., the system uses its knowledge of users
and of the product space to select sets of products, albeit sets
that it hopes will provoke the user into volunteering further
preferences [7]. In collaborative filters also, the user model
(the ratings profile) is for product retrieval and ranking.
But in information recommendation, the user model is
used to guide the user’s search rather than to retrieve or rank
products. Work on question selection in dynamic dialogues
can be seen as an example of information recommendation.
The system dynamically selects questions to elicit user pref-
erences. Its goal is to choose a sequence of questions that
most effectively homes in on desirable products. In most
such work, questions are selected based on the user’s partial
query and the product distribution. But, Schmitt’s simVar
system also builds and uses simple user models too [10].
Reilly et al.’s use of the query history to dynamically rec-
ommend compound critiques can also be regarded as infor-
mation recommendation [8]. In their work, the system shows
the user some products which the user can critique, but it
also advises the user by displaying dynamically-computed
critiques that are known to be satisfiable, which the user
can select.
Section 2 describes our assumptions about how products
and queries are represented; it describes users’ utility func-
tions; and it describes the idea of a conversational product
recommender in which the user repeatedly edits and resub-
mits her query in a search for the products of highest utility.
The section also explains the assumptions we make about
user rationality. Section 3 explains how the advisor can infer
the constraints that it adds to the user model and it explains
different strategies for giving advice to the user. Section 4
presents our experimental methodology and results.
2. SEARCHING FOR PRODUCTS
2.1 Products and Queries
We assume a very simple product data model. Products
are described by a fixed number of n Boolean features. For
instance, hotels may have: a sauna, a pool, parking, etc.
Hence, each product can be represented by a fixed-length
string of bits, p = p1, . . . , pn, where pi = 1 means that the
product has the ith feature and pi = 0 means that it does
not have the feature.
User queries are defined by a product pattern q = q1, . . . , qn,
where qi is either 1 or 0, i = 1, . . . , n. If qi = 1, the user is
interested in products that have the ith feature; if qi = 0,
the user has not (yet) declared any special interest in the ith
feature. It must be kept in mind that, e.g., q = 1010 does
not mean that the user wants to see products that lack the
second and fourth features; it simply means that the user
wants a product that has the first and the third features.
Given query q, the query engine retrieves products P
where if qi = 1 then pi = 1, for all pi ∈ P . In other words,
each retrieved product must possess at least all the features
that are explicitly requested in the query, but may possess
other features too. For example, q = 1010 is matched by
products such as 1011 and 1111 as well as 1010; it is not
matched by products such as 0010. We describe a query as
satisfiable if it is matched by at least one product; otherwise,
we call it unsatisfiable. Given query q, we expect the query
engine to at least tell the user whether q is satisfiable or not.
2.2 Utility
We assume the user has a fixed utility function. The util-
ity of product p = p1, . . . , pn is defined as follows:
U(p) = w1p1 + . . . + wnpn
where (w1, . . . , wn) is a vector of weights. We assume only
that the weights are non-negative and do not exceed 1 (0 ≤
wi ≤ 1) and that there is at least one non-zero weight
( wi > 0). The weight of a feature says how strong the de-
sire of the user for that feature is. If a weight wi is zero, then
the user has no desire for the ith feature; if wi > wj , then
the ith feature is preferred to the jth; if wi = wj (i 6= j),
then the user is indifferent between the ith and jth features.
We assume that the goal of the user is to find a product that
maximises the utility function.
We can also define the utility of a query q = q1, . . . , qn.
In fact, we define two types of query utility. The potential
utility of query q is given by
U(q) = w1q1 + . . .+ wnqn
Hence, the potential utility of a query is the utility to the
user of a product that offers exactly the features requested
in the query, whether such products exist or not.
The actual utility of query q is given by
V (q) =


0 if q is unsatisfiable
U(q) otherwise.
Hence, the actual utility of a query is zero if no product
matches the query; otherwise, the actual utility equals the
potential utility.
2.3 Utility Gain
In the kind of conversational recommender that we are
considering in this work, the user is engaged in an inter-
active, incremental search process. The states of the search
space are different queries. The successors of state (or query)
q, succ(q), will be the queries that the user obtains by editing
q. succ(q) will depend on the actions that the user interface
makes available, e.g., it might allow the user to add a feature
to a query, to delete a feature from a query, to restart, etc.
The user’s goal in query editing is to move to a state with
higher actual utility.
We assume a certain rationality in user behaviour. A min-
imal requirement is that a user will not search for products
that are less preferable than those already selected:
Axiom 1. If q is the user’s current query and q′ is a suc-
cessor query, q′ ∈ succ(q), then the user will try q′ if and
only if U(q′) ≥ U(q), and may choose to accept q′ if and
only if V (q′) 6= 0.
In other words, we assume that the user will only try q′
(i.e. issue the query to the query engine) if its potential util-
ity is greater than or equal to q’s; and then the user may
choose to accept q′ (i.e. move to this state) if q′ has higher
66