《电子商务 E-business》阅读文献：Case-Based Recommendation

Case-Based Recommendation Barry Smyth The School of Computer Science and Informatics, University College Dublin, Belfield, Dublin 4, Ireland Changing worlds Ltd South County Business Park, Leopardstown, Dublin 18. Ireland. Barry. Smyth@ucd. ie paces.a good example is when they are used to help users to access onlinepiox o Abstract. Recommender systems try to help users access complex informati uct catalogs, where recommender systems have proven to be especially useful for making product suggestions in response to evolving user needs and preferences Case-based recommendation is a form of content -based recommendation that is well suited to many product recommendation domains where individual products are described in terms of a well defined set of features(e. g, price, colour, make etc. ) These representations allow case-based recommenders to make judgments about product similarities in order to improve the quality of their recommenda- tions and as a result this type of approach has proven to be very successful in many e-commerce settings, especially when the needs and preferences of users are ill-defined, as they often are. In this chapter we will describe the basic ap- proach to case-based recommendation, highlighting how it differs from other recommendation technologies, and introducing some recent advances that have ed to more powerful and flexible recommender systems 11.1 Introduction Recently I wanted to buy a new digital camera. I had a vague idea of what I wanted-a 6 mega-pixel digital SLR from a good manufacturer-but it proved difficult and time consuming to locate a product online that suited my needs, especially as these needs evolved during my investigations. Many online stores allowed me to browse or nar igate through their product catalog by choosing from a series of static features(e.g manufacturer, camera type, resolution, level of zoom etc. ) Each time I selected a fea- ture I was presented with the set of cameras with this feature and I could then go on to choose another feature to further refine the presented products. Other stores allowed me to search for my ideal camera by entering a query(e. g. " digital slr 6 mega-pixels") and presented me with a list of results which I could then browse at my leisure Both of these access options were helpful in different ways-in the beginning I preferred to browse through catalogs but, after getting a feel for the various features and compromises, I tended to use search-based interfaces--however neither provided Brusilovsky, A. Kobsa, and w. Nejdl(Eds ) The Adaptive Web, LNCS 4321, Pp. 342-376, 2007. C Springer-Verlag Berlin Heidelberg 2007

11 Case-Based Recommendation Barry Smyth1,2 1 The School of Computer Science and Informatics, University College Dublin, Belfield, Dublin 4, Ireland 2 ChangingWorlds Ltd. South County Business Park, Leopardstown, Dublin 18, Ireland. Barry.Smyth@ucd.ie Abstract. Recommender systems try to help users access complex information spaces. A good example is when they are used to help users to access online prod￾uct catalogs, where recommender systems have proven to be especially useful for making product suggestions in response to evolving user needs and preferences. Case-based recommendation is a form of content-based recommendation that is well suited to many product recommendation domains where individual products are described in terms of a well defined set of features (e.g., price, colour, make, etc.). These representations allow case-based recommenders to make judgments about product similarities in order to improve the quality of their recommenda￾tions and as a result this type of approach has proven to be very successful in many e-commerce settings, especially when the needs and preferences of users are ill-defined, as they often are. In this chapter we will describe the basic ap￾proach to case-based recommendation, highlighting how it differs from other recommendation technologies, and introducing some recent advances that have led to more powerful and flexible recommender systems. 11.1 Introduction Recently I wanted to buy a new digital camera. I had a vague idea of what I wanted—a 6 mega-pixel digital SLR from a good manufacturer—but it proved difficult and time consuming to locate a product online that suited my needs, especially as these needs evolved during my investigations. Many online stores allowed me to browse or nav￾igate through their product catalog by choosing from a series of static features (e.g., manufacturer, camera type, resolution, level of zoom etc.). Each time I selected a fea￾ture I was presented with the set of cameras with this feature and I could then go on to choose another feature to further refine the presented products. Other stores allowed me to search for my ideal camera by entering a query (e.g. “digital slr, 6 mega-pixels”) and presented me with a list of results which I could then browse at my leisure. Both of these access options were helpful in different ways—in the beginning I preferred to browse through catalogs but, after getting a feel for the various features and compromises, I tended to use search-based interfaces—however neither provided P. Brusilovsky, A. Kobsa, and W. Nejdl (Eds.): The Adaptive Web, LNCS 4321, pp. 342–376, 2007.
c Springer-Verlag Berlin Heidelberg 2007

11 Case-Based Recommendation 343 me with the flexibility I really sought. For a start, all of the stores I tried tended to slavishly respect my queries. This was especially noticeable when no results could be returned to satisfy my stated needs; this is often referred to as stonewalling [17]. For instance, looking for a 6 mega-pixel digital SiR for under $200 proved fruitless- unsurprising perhaps to those in the know-and left me with no choice but to start my search again. This was especially frustrating when there were many cameras that were similar enough to my query to merit suggestion. Moreover, stonewalling is further compounded by a diversity problem: I was frequently presented with sets of product hat were all very similar to each other thus failing to offer me a good set of alternatives At other times I would notice a camera that was almost perfect, aside from perhaps one or two features, but it was usually difficult to provide this form of feedback directly This feedback problem prevented me from requesting"another camera like this one bu with more optical zoom and/or a lower price", for instance In all, perhaps one of the most frustrating aspects of my search was the apparent inability of most online stores to learn anything about my preferences over time. In my opinion shopping for an expensive item such as a digital camera is an exercise in pa tience and deliberation, and one that is likely to involve many return visits to particula online stores. Unfortunately, despite the fact that I had spent a significant time and effort searching and browsing for cameras during previous visits none of the stores I visited had any facility to remember my previous interactions or preferences. For instance, my reluctance to purchase a very expensive cameraL never accepted recommendations for cameras above $1000--should have been recognised and factored into the stores recommendations, but it was not. As a result many of my interactions turned out to be requests for less expensive suggestions. This preference problem meant that starting my searches from scratch became a regular feature of these visits sA Recommender systems are designed to address many of the prol blems mentioned above, and more besides, by offering users a more intelligent approach to navigat- ng and searching complex information spaces. They have been especially useful in many e-commerce domains with many stores using recommendation technologies to help convert browsers into buyers by providing intelligent and timely sales support and product suggestions; see for example Chapter 16 of this book [38] for a survey of recommendation techniques in an e-commerce setting. One of the key features of many recommendation technologies is the ability to consider the needs and preferences of the individual when it comes to generating personalized recommendations or sug- gestions. We will return to this issue later in this chapter but also refer the interested reader to related work on the development of personalization technologies. For exam ple, Chapters 2[35] and 4 [44] of this book consider different approaches to learnin and modeling the preferences of users while Chapters 3 [62], 6[61], and 18 [8] of this book consider different ways in which user models may be harnessed to provide users with more personalized access to online information and services. Indeed, while many recommendation and personalization technologies focus on the needs of the individual some researchers have begun to consider group recommendation scenarios where the potentially competing preferences of a number of individuals need to be considered see for example Chapter 20 [41]of this book

11 Case-Based Recommendation 343 me with the flexibility I really sought. For a start, all of the stores I tried tended to slavishly respect my queries. This was especially noticeable when no results could be returned to satisfy my stated needs; this is often referred to as stonewalling [17]. For instance, looking for a 6 mega-pixel digital SLR for under $200 proved fruitless— unsurprising perhaps to those ‘in the know’—and left me with no choice but to start my search again. This was especially frustrating when there were many cameras that were similar enough to my query to merit suggestion. Moreover, stonewalling is further compounded by a diversity problem: I was frequently presented with sets of products that were all very similar to each other thus failing to offer me a good set of alternatives. At other times I would notice a camera that was almost perfect, aside from perhaps one or two features, but it was usually difficult to provide this form of feedback directly. This feedback problem prevented me from requesting “another camera like this one but with more optical zoom and/or a lower price”, for instance. In all, perhaps one of the most frustrating aspects of my search was the apparent inability of most online stores to learn anything about my preferences over time. In my opinion shopping for an expensive item such as a digital camera is an exercise in pa￾tience and deliberation, and one that is likely to involve many return visits to particular online stores. Unfortunately, despite the fact that I had spent a significant time and effort searching and browsing for cameras during previous visits none of the stores I visited had any facility to remember my previous interactions or preferences. For instance, my reluctance to purchase a very expensive camera—I never accepted recommendations for cameras above $1000—should have been recognised and factored into the store’s recommendations, but it was not. As a result many of my interactions turned out to be requests for less expensive suggestions. This preference problem meant that starting my searches from scratch became a regular feature of these visits. Recommender systems are designed to address many of the problems mentioned above, and more besides, by offering users a more intelligent approach to navigat￾ing and searching complex information spaces. They have been especially useful in many e-commerce domains with many stores using recommendation technologies to help convert browsers into buyers by providing intelligent and timely sales support and product suggestions; see for example Chapter 16 of this book [38] for a survey of recommendation techniques in an e-commerce setting. One of the key features of many recommendation technologies is the ability to consider the needs and preferences of the individual when it comes to generating personalized recommendations or sug￾gestions. We will return to this issue later in this chapter but also refer the interested reader to related work on the development of personalization technologies. For exam￾ple, Chapters 2 [35] and 4 [44] of this book consider different approaches to learning and modeling the preferences of users while Chapters 3 [62], 6 [61], and 18 [8] of this book consider different ways in which user models may be harnessed to provide users with more personalized access to online information and services. Indeed, while many recommendation and personalization technologies focus on the needs of the individual, some researchers have begun to consider group recommendation scenarios where the potentially competing preferences of a number of individuals need to be considered; see for example Chapter 20 [41] of this book

Recommendation techniques come in two basic flavours. Collaborative filtering ap hes rely on the availability of user ratings information(e. g. "John likes items A, Id c but dislikes items e and F"and make suggestions for a target user based on the items that similar users have liked in the past, without relying on any information bout the items themselves other than their ratings; see Chapter 9[83] of this book for a more detailed account of collaborative filtering approaches. In contrast content-based techniques rely on item descriptions and generate recommendations from items that are similar to those the target user has liked in the past, without directly relying on the pref- erences of other users; see Chapter 10 [69]of this book for a detailed account of pure content-based approaches Case-based recommenders implement a particular style of content-based recom mendation that is very well suited to many product recommendation scenarios; see also [16]. They rely on items or products being represented in a structured way using a well defined set of features and feature values: for instance. in a travel recommender a particular vacation might be presented in terms of its price, duration, accommodation, location, mode of transport, etc. In turn the availability of similarity knowledge makes it possible for case-based recommenders to make fine-grained judgments about the sim- ilarities between items and queries for informing high-quality suggestions to the user. Case-based recommender systems are the subject of this chapter, where we will draw on a range of examples from a variety of recommender systems, both research proto- types and deployed applications. We will explain their origins in case-based reasoning research [1, 31, 46, 101] and their basic mode of operation as recommender systems In particular, we will look at how case-based recommenders deal with the issues high lighted above in terms of their approach to selection similarity, recommendation diver- sity, and the provision of flexible feedback options. In addition we will consider the use of case-based recommendation techniques to produce suggestions that are personalized for the needs of the individual user and in this way present case-based approaches as one important solution for Web personalization problems: see also Chapters 2351, 3 [62], and 16 [38] in this book for related work in the area of Web personalization 11.2 Towards Case-Based recommendation Case-based recommender systems have their origins in case-based reasoning(CBR) techniques [1, 46, 101, 48, 99]. Early case-based reasoning systems were used in a variety of problem solving and classification tasks and can be distinguished from more traditional problem solving techniques by their reliance on concrete experiences instead of problem solving knowledge in the form of codified rules and strong domain models Case-based reasoning systems rely on a database(or case base)of past problem solving experiences as their primary source of problem-solving expertise. Each case is typically made up of a specification part, which describes the problem at hand, and a solution part, which describes the solution used to solve this problem. New problems are solved by retrieving a case whose specification is similar to the current target problem and then adapting its solution to fit the target situation. For example, CLAVIER [39]is a case-based reasoning system used by Lockheed to assist in determining the layout of materials to be cured in an autoclave (i.e, a large convection oven used, in this

344 B. Smyth Recommendation techniques come in two basic flavours. Collaborative filtering ap￾proaches rely on the availability of user ratings information (e.g. “John likes items A, B and C but dislikes items E and F” and make suggestions for a target user based on the items that similar users have liked in the past, without relying on any information about the items themselves other than their ratings; see Chapter 9 [83] of this book for a more detailed account of collaborative filtering approaches. In contrast content-based techniques rely on item descriptions and generate recommendations from items that are similar to those the target user has liked in the past, without directly relying on the pref￾erences of other users; see Chapter 10 [69] of this book for a detailed account of pure content-based approaches. Case-based recommenders implement a particular style of content-based recom￾mendation that is very well suited to many product recommendation scenarios; see also [16]. They rely on items or products being represented in a structured way using a well defined set of features and feature values; for instance, in a travel recommender a particular vacation might be presented in terms of its price, duration, accommodation, location, mode of transport, etc. In turn the availability of similarity knowledge makes it possible for case-based recommenders to make fine-grained judgments about the sim￾ilarities between items and queries for informing high-quality suggestions to the user. Case-based recommender systems are the subject of this chapter, where we will draw on a range of examples from a variety of recommender systems, both research proto￾types and deployed applications. We will explain their origins in case-based reasoning research [1, 31, 46, 101] and their basic mode of operation as recommender systems. In particular, we will look at how case-based recommenders deal with the issues high￾lighted above in terms of their approach to selection similarity, recommendation diver￾sity, and the provision of flexible feedback options. In addition we will consider the use of case-based recommendation techniques to produce suggestions that are personalized for the needs of the individual user and in this way present case-based approaches as one important solution for Web personalization problems; see also Chapters 2 [35], 3 [62], and 16 [38] in this book for related work in the area of Web personalization. 11.2 Towards Case-Based Recommendation Case-based recommender systems have their origins in case-based reasoning (CBR) techniques [1, 46, 101, 48, 99]. Early case-based reasoning systems were used in a variety of problem solving and classification tasks and can be distinguished from more traditional problem solving techniques by their reliance on concrete experiences instead of problem solving knowledge in the form of codified rules and strong domain models. Case-based reasoning systems rely on a database (or case base) of past problem solving experiences as their primary source of problem-solving expertise. Each case is typically made up of a specification part, which describes the problem at hand, and a solution part, which describes the solution used to solve this problem. New problems are solved by retrieving a case whose specification is similar to the current target problem and then adapting its solution to fit the target situation. For example, CLAVIER [39] is a case-based reasoning system used by Lockheed to assist in determining the layout of materials to be cured in an autoclave (i.e., a large convection oven used, in this

Case-Base Similarity Target Specification Knowledg (parts list spec ○○◎ ◇◇△ Retrieve ○○口 Ct Learn Adapt ○○囗 ◎◎◎ Adaptation Target Solution Rules (parts layout Fig. 1l. 1. CLAVIER uses CBR to design layout configurations for a set of parts to be cured in an autoclave. This is a complex layout task that does not lend itself to a traditional knowledge based approach. However a case base of high-quality past layouts can be readily assembled. New layouts for a target parts-list can then be produced by retrieving a case with a similar parts-list and adapting its layout. If successful this new layout can then be learned by storing it in the case base as a new case case, for the curing of composite materials for aerospace applications). CLAVIER has the job of designing a good layout-one that will maximise autoclave throughput for a new parts-list. The rules for determining a good layout are not well understood but previous layouts that have proved to be successful are readily available. CLAVIER uses these previous layout examples as the cases in its case base. Each case is made up of a parts-list (its specification) and the particular layout used(its solution). Nev layouts for a new parts-list are determined by matching the new parts-list against these cases and adapting the layout solution used by the most similar case; see Figure 11.1 CLAVIER has been a huge practical success and has been in use for a number of years by Lockheed, virtually eliminating the production of low-quality parts that must crapped, and saving thousands of dollars each month Case-based recommenders borrow heavily from the core concepts of retrieval and milarity in case-based reasoning. Items or products are represented as cases and rec- ommendations are generated by retrieving those that are most similar to a users

11 Case-Based Recommendation 345 Case-Base Target Specification (parts list) Retrieve Adapt Target Solution (parts layout) Learn Similarity Knowledge Adaptation Rules spect c1,…cn cbest sol ct t ct Fig. 11.1. CLAVIER uses CBR to design layout configurations for a set of parts to be cured in an autoclave. This is a complex layout task that does not lend itself to a traditional knowledge￾based approach. However a case base of high-quality past layouts can be readily assembled. New layouts for a target parts-list can then be produced by retrieving a case with a similar parts-list and adapting its layout. If successful this new layout can then be learned by storing it in the case base as a new case. case, for the curing of composite materials for aerospace applications). CLAVIER has the job of designing a good layout—one that will maximise autoclave throughput— for a new parts-list. The rules for determining a good layout are not well understood but previous layouts that have proved to be successful are readily available. CLAVIER uses these previous layout examples as the cases in its case base. Each case is made up of a parts-list (its specification) and the particular layout used (its solution). New layouts for a new parts-list are determined by matching the new parts-list against these cases and adapting the layout solution used by the most similar case; see Figure 11.1. CLAVIER has been a huge practical success and has been in use for a number of years by Lockheed, virtually eliminating the production of low-quality parts that must be scrapped, and saving thousands of dollars each month. Case-based recommenders borrow heavily from the core concepts of retrieval and similarity in case-based reasoning. Items or products are represented as cases and rec￾ommendations are generated by retrieving those cases that are most similar to a user’s

46 B. Smyth query or profile. The simplest form of case-based recommendation is presented in Fig- ure 11.2. In this figure we use the example of a digital camera recommender system, with the product case base made up of detailed descriptions of individual digital cam- eras. When the user submits a target query--in this instance providing a relatively vague description of their requirements in relation to camera price and pixel resolution--they re presented with a ranked list of k recommendations which represent the top k most milar cases that match the target query As a form of content-based recommendation Product Case-Base Knowledge Case Price: 1000 Pixel: 6 C, sim(t, C,)1, CIsm(t, c,)), 11. 2. In its simplest form a case-based recommendation system will nk product by comparing the user's target query to the descriptions of products In Its ca base using similarity knowledge to identify products that are close matches to the target query (see, for example, [5, 26, 63, 78, 94] and also Chapter 10 [69] of this book) case-base recommenders generate their recommendations by looking to the item descriptions, with items suggested because they have similar descriptions to the user's query. There are two important ways in which case-based recommender systems can be distinguished from other types of content-based systems: (1)the manner in which products are rep- resented; and (2) the way in which product similarity is assessed. Both of these will be discussed in detail in the following sections. 11.2.1 Case Representation Normally content-based recommender systems operate in situations where content items are represented in an unstructured or semi-structured manner. For example, the News Dude content-recommender. which recommends news articles to users. assumes

346 B. Smyth query or profile. The simplest form of case-based recommendation is presented in Fig￾ure 11.2. In this figure we use the example of a digital camera recommender system, with the product case base made up of detailed descriptions of individual digital cam￾eras. When the user submits a target query—in this instance providing a relatively vague description of their requirements in relation to camera price and pixel resolution—they are presented with a ranked list of k recommendations which represent the top k most similar cases that match the target query. As a form of content-based recommendation Product Case-Base Price: 1000 Pixel: 6 Target Query, t Case Retrieval Similarity Knowledge c1,…cn Product Recommendations c1 {sim(t, c1)}, : ck {sim(t, c1)}, c1,…ck Fig. 11.2. In its simplest form a case-based recommendation system will retrieve and rank product suggestions by comparing the user’s target query to the descriptions of products stored in its case base using similarity knowledge to identify products that are close matches to the target query. (see, for example, [5, 26, 63, 78, 94] and also Chapter 10 [69] of this book) case-based recommenders generate their recommendations by looking to the item descriptions, with items suggested because they have similar descriptions to the user’s query. There are two important ways in which case-based recommender systems can be distinguished from other types of content-based systems: (1) the manner in which products are rep￾resented; and (2) the way in which product similarity is assessed. Both of these will be discussed in detail in the following sections. 11.2.1 Case Representation Normally content-based recommender systems operate in situations where content items are represented in an unstructured or semi-structured manner. For example, the NewsDude content-recommender, which recommends news articles to users, assumes

347 text-based news stories and leverages a range of keyword-based content analysis tech niques during recommendation; see for example, 19] and Chapter 18[8]in this book In contrast, case-based recommender systems rely on more structured representations of item content. These representations are similar to those used to represent case- knowledge in case-based reasoners. For example, they often use a set of well-defined features and feature values to describe items. rather than free-form text. This reliance on structured content means that case-based recommenders are particularly well adapted to many consumer recommendation domains, particularly e-commerce domains, where detailed feature-based product descriptions are often readily available Cannon EOS D60 63 0 Num of Batteries 1.0 BP-511 Cable USB and video Software CD-Rom featuring Adobe Photosh Price Fig. 11.3. An example product case from a digital camera product catalog Figure 11.3 shows one such example product case from a catalog of cameras. The case is for a Canon digital camera and, as can be seen, the product details are captured us ng ll different features(e. g, manufacturer model, memory type, price, etc. )with each feature associated with one of a well-defined space of possible feature values(e. g, the manufacturer feature values are drawn from a well-defined set of possible manufactur ers such as Canon, Nikon, Sony etc. ) The example also highlights how different types of features can be used within a product description. In this case, a mixture of numeric and nominal features are used. For instance, price is an example of a numeric feature, which obviously represents the cost of the camera, and can take on values anywhere in a range of possible prices, from about $100 to upwards of $3000. Alternatively, memory type is a nominal feature, whose values come from a well-defined set of alternatives corresponding to the 4 or 5 different memory card options that are commonly used by digital cameras. The Entree recommender is another good example of a case-based recommender system. This system will be explored in more detail in Section 11.4 but suffice it to say that Entree is designed to make restaurant suggestions; see Figure 11.4 In terms of its core representation, Entree also uses a structured case format-although

11 Case-Based Recommendation 347 text-based news stories and leverages a range of keyword-based content analysis tech￾niques during recommendation; see for example, [9] and Chapter 18 [8] in this book. In contrast, case-based recommender systems rely on more structured representations of item content. These representations are similar to those used to represent case￾knowledge in case-based reasoners. For example, they often use a set of well-defined features and feature values to describe items, rather than free-form text. This reliance on structured content means that case-based recommenders are particularly well adapted to many consumer recommendation domains, particularly e-commerce domains, where detailed feature-based product descriptions are often readily available. Fig. 11.3. An example product case from a digital camera product catalog. Figure 11.3 shows one such example product case from a catalog of cameras. The case is for a Canon digital camera and, as can be seen, the product details are captured us￾ing 11 different features (e.g., manufacturer, model, memory type, price, etc.) with each feature associated with one of a well-defined space of possible feature values (e.g., the manufacturer feature values are drawn from a well-defined set of possible manufactur￾ers such as Canon, Nikon, Sony etc.). The example also highlights how different types of features can be used within a product description. In this case, a mixture of numeric and nominal features are used. For instance, price is an example of a numeric feature, which obviously represents the cost of the camera, and can take on values anywhere in a range of possible prices, from about $100 to upwards of $3000. Alternatively, memory type is a nominal feature, whose values come from a well-defined set of alternatives corresponding to the 4 or 5 different memory card options that are commonly used by digital cameras. The Entree recommender is another good example of a case-based recommender system. This system will be explored in more detail in Section 11.4 but suffice it to say that Entree is designed to make restaurant suggestions; see Figure 11.4. In terms of its core representation, Entree also uses a structured case format—although

taee pesudo hicago restaurant you chose is Michael Jordan 500N, LaSale St (G ve& Iling s St) Chicago, 312-644-3055 Excelent Decor, Good Service Good Facc, Busines3 Scene, Hp Pace To Be, Privete Rooms Av ivate Paties, Pcop aet Great for Pepole vrarchina See the Came Singles scene (Ohin S., Chicage, 312-2G6 :15-30 ing See the geneart Fig. 11.4. Entree [21, 22] recommends restaurants to users based on a variety of features such as the presentation in Figure 11 12 is largely textual the basic case representation is fun damentally feature-based--using features such as price, cuisine ty tmo to represent each restaurant case 11.2.2 Similarity Assessment The second important distinguishing feature of case-based recommender systems re- lates to their use of various sophisticated approaches to similarity assessment when it comes to judging which cases to retrieve in response to some user query. Because case based recommenders rely on structured case representations they can take advantage of more structured approaches to similarity assessment than their content-based cousins For example, traditional content-based techniques tend to use keyword-based similar- ity metrics, measuring the similarity between a user query and a product in terms of the frequency of occurrence of overlapping query terms within the product text. If the user is looking for a"$1000 6 mega-pixel DSLR"then cameras with all of these terms will be rated highly, and depending on the strength of the similarity criterion used, if no cameras exist with all of these terms then none may be retrieved. We have already highlighted this type of retrieval inflexibility(stonewalling) as a critical problem in the introduction to this chapter. Any reasonable person would be happy to receive a recom- mendation for a"$900 6.2 mega-pixel digital SLR", for the above query, even though strictly speaking there is no overlap between the terms used in this description and the query. Case-based recommenders can avail of more sophisticated similarity metrics that are based on an explicit mapping of case features and the availability of specialised feature level similarity knowledge. An online property recommender might use case-

348 B. Smyth Fig. 11.4. Entree [21, 22] recommends restaurants to users based on a variety of features such as price, cuisine type, atmosphere, etc.. the presentation in Figure 11.12 is largely textual the basic case representation is fun￾damentally feature-based—using features such as price, cuisine type, atmosphere, etc. to represent each restaurant case. 11.2.2 Similarity Assessment The second important distinguishing feature of case-based recommender systems re￾lates to their use of various sophisticated approaches to similarity assessment when it comes to judging which cases to retrieve in response to some user query. Because case￾based recommenders rely on structured case representations they can take advantage of more structured approaches to similarity assessment than their content-based cousins. For example, traditional content-based techniques tend to use keyword-based similar￾ity metrics, measuring the similarity between a user query and a product in terms of the frequency of occurrence of overlapping query terms within the product text. If the user is looking for a “$1000 6 mega-pixel DSLR” then cameras with all of these terms will be rated highly, and depending on the strength of the similarity criterion used, if no cameras exist with all of these terms then none may be retrieved. We have already highlighted this type of retrieval inflexibility (stonewalling) as a critical problem in the introduction to this chapter. Any reasonable person would be happy to receive a recom￾mendation for a “$900 6.2 mega-pixel digital SLR”, for the above query, even though strictly speaking there is no overlap between the terms used in this description and the query. Case-based recommenders can avail of more sophisticated similarity metrics that are based on an explicit mapping of case features and the availability of specialised feature level similarity knowledge. An online property recommender might use case-

based techniques to make suggestions that are similar to a target query even when exact matches are not available. For example, a user who looking for a "2 bedroom apartment in Dublin with a rent of 1150 euro"might receive recommendations for properties that match the bedroom feature and that are similar to the target query in terms of price and location; the recommendations might offer slightly higher or lower priced properties in a nearby location when no exact matches are available (11.1) ∑/=1.nwi Assessing similarity at the case level (or between the target query and a candidate case) bviously involves combining the individual feature level similarities for the relevant features. The usual approach is to use a weighted sum metric such as that shown in Equation 11.1. In brief, the similarity between some target query, t and some candi- date case(or item), c, is the weighted sum of the individual similarities between the corresponding features of t and c, namely t; and ci. Each weight encodes the relative mportance of a particular feature in the similarity assessment process and each indi vidual feature similarity is calculated according to a similarity function that is defined for that feature, simi (ti, ci). For instance, looking to the property recommender example above, if rent is very important to the user then the weight associated with this feature will be higher than the weights associated with less important features. In turn, when it comes to comparing the query and a case in terms of their rent the recommender system may draw on a specialised similarity metric designed for comparing monthly rents. a different metric might be used for comparing the number of bedrooms or the property type. We must also consider the source of the individual feature level similarities and how they can be calculated. For example, returning to our camera recommender system, consider a numeric feature such as pixel resolution. The target query and a candidate case might be compared in terms of this feature using a similarity metric with the sort of similarity profile shown in Figure 11.5(a): maximum similarity is achieved when the pixel resolution of a candidate case matches that of the target query, and for cases with higher or lower pixel resolution there is a corresponding decline in similarity. This is an example of a symmetric similarity metric because there is no bias in favour of either higher or lower resolution cases simplice(Pt, Pc)=1--IPt-Pel ax(pr, pc) ometimes symmetric similarity metrics are not appropriate. For instance, consider the price feature: it is reasonable to expect that a user will view cameras with prices(pc) that are lower than their target price(pt)to be preferable to cameras with higher prices, all other things being equal. The similarity metric in Equation 11. 2 is used in many recommender systems(e.g, see [52, 75]) as one way to capture this notion and the metric displays a similarity profile similar to that shown in Figure 11.5(b). For instance consider a S1000 target price and two candidate cases, one with a price of $500 and one for $1500. In terms of the symmetric similarity metric represented by Figure 11.5(a), the latter candidate corresponds to the point x in Figure 11.5(a) and the former to point y

11 Case-Based Recommendation 349 based techniques to make suggestions that are similar to a target query even when exact matches are not available. For example, a user who looking for a “2 bedroom apartment in Dublin with a rent of 1150 euro” might receive recommendations for properties that match the bedroom feature and that are similar to the target query in terms of price and location; the recommendations might offer slightly higher or lower priced properties in a nearby location when no exact matches are available. Similarity(t,c) = ∑i=1..nwi ∗ simi(ti,ci) ∑i=1..nwi (11.1) Assessing similarity at the case level (or between the target query and a candidate case) obviously involves combining the individual feature level similarities for the relevant features. The usual approach is to use a weighted sum metric such as that shown in Equation 11.1. In brief, the similarity between some target query, t and some candi￾date case (or item), c, is the weighted sum of the individual similarities between the corresponding features of t and c, namely ti and ci. Each weight encodes the relative importance of a particular feature in the similarity assessment process and each indi￾vidual feature similarity is calculated according to a similarity function that is defined for that feature, simi(ti,ci). For instance, looking to the property recommender example above, if rent is very important to the user then the weight associated with this feature will be higher than the weights associated with less important features. In turn, when it comes to comparing the query and a case in terms of their rent the recommender system may draw on a specialised similarity metric designed for comparing monthly rents. A different metric might be used for comparing the number of bedrooms or the property type. We must also consider the source of the individual feature level similarities and how they can be calculated. For example, returning to our camera recommender system, consider a numeric feature such as pixel resolution. The target query and a candidate case might be compared in terms of this feature using a similarity metric with the sort of similarity profile shown in Figure 11.5(a); maximum similarity is achieved when the pixel resolution of a candidate case matches that of the target query, and for cases with higher or lower pixel resolution there is a corresponding decline in similarity. This is an example of a symmetric similarity metric because there is no bias in favour of either higher or lower resolution cases. simprice(pt, pc) = 1− |pt − pc| max(pt, pc) (11.2) Sometimes symmetric similarity metrics are not appropriate. For instance, consider the price feature: it is reasonable to expect that a user will view cameras with prices (pc) that are lower than their target price (pt) to be preferable to cameras with higher prices, all other things being equal. The similarity metric in Equation 11.2 is used in many recommender systems (e.g., see [52, 75]) as one way to capture this notion and the metric displays a similarity profile similar to that shown in Figure 11.5(b). For instance, consider a $1000 target price and two candidate cases, one with a price of $500 and one for $1500. In terms of the symmetric similarity metric represented by Figure 11.5(a), the latter candidate corresponds to the point x in Figure 11.5(a) and the former to point y

p, < pc 0 pt -pc Fig. 11.5. Two example similarity profiles for numeric similarity metrics: (a)corresponds to a standard symmetric similarity metric;(b) corresponds to an asymmetric metric that gives prefer- ence to features values that are lower than the targets value For both cases the similarity assessment is the same, reflecting that both differ from the target price by the same amount, $500, with no preference given to whether a case is less or more expensive. These cases are plotted in the same way in Figure 11.5(b) but now we see that the more expensive case(point x)has a lower similarity than the heaper camera(point y). Even though both candidates differ by $500, preference is given to the cheaper case To evaluate the similarity of non-numeric features in a meaningful way requires dditional domain knowledge. For example, in a vacation recommender it might be im- portant to be able to judge the similarities of cases of different vacation types Is a skiing holiday more similar to a walking holiday than it is to a city break or a beach holiday? One way to make such judgments is by referring to suitable domain knowledge such as an ontology of vacation types. In Figure 11.6 we present part of what such an on gy might look like with different feature values represented as nodes and simil are values grouped near to each other. In this way, the similarity between two ar- bitrary nodes can be evaluated as an inverse function of the distance between them or the distance to their nearest common ancestor. Accordingly, a skiing holiday is more similar to a walking holiday( they share a direct ancestor, activity holidays)than it is to a beach holiday, where the closest common ancestor is the ontology root node 11.2.3 Acquiring Similarity Knowledge Similarity assessment is obviously a key issue for case-based reasoning and case- based recommender systems. Of course the availability and use of similarity knowledge (feature-based similarity measures and weighting functions )is an important distinguish ing feature of case-based recommendation. Although further detailed discussion of this particular issue is beyond the scope of this chapter, it is nonetheless worth consider ing the origin of this knowledge in many systems. For the most part this knowledge is hand-coded: similarity tables and trees, such as the vacation ontology above, are made

350 B. Smyth Similarity 1 0 pt - pc pt pc 0 Similarity 1 0 pt - pc pt pc 0 x y x y (a) (b) Fig. 11.5. Two example similarity profiles for numeric similarity metrics: (a) corresponds to a standard symmetric similarity metric; (b) corresponds to an asymmetric metric that gives prefer￾ence to features values that are lower than the target’s value. For both cases the similarity assessment is the same, reflecting that both differ from the target price by the same amount, $500, with no preference given to whether a case is less or more expensive. These cases are plotted in the same way in Figure 11.5(b) but now we see that the more expensive case (point x) has a lower similarity than the cheaper camera (point y). Even though both candidates differ by $500, preference is given to the cheaper case. To evaluate the similarity of non-numeric features in a meaningful way requires additional domain knowledge. For example, in a vacation recommender it might be im￾portant to be able to judge the similarities of cases of different vacation types. Is a skiing holiday more similar to a walking holiday than it is to a city break or a beach holiday? One way to make such judgments is by referring to suitable domain knowledge such as an ontology of vacation types. In Figure 11.6 we present part of what such an on￾tology might look like with different feature values represented as nodes and similar feature values grouped near to each other. In this way, the similarity between two ar￾bitrary nodes can be evaluated as an inverse function of the distance between them or the distance to their nearest common ancestor. Accordingly, a skiing holiday is more similar to a walking holiday (they share a direct ancestor, activity holidays) than it is to a beach holiday, where the closest common ancestor is the ontology root node. 11.2.3 Acquiring Similarity Knowledge Similarity assessment is obviously a key issue for case-based reasoning and case￾based recommender systems. Of course the availability and use of similarity knowledge (feature-based similarity measures and weighting functions) is an important distinguish￾ing feature of case-based recommendation. Although further detailed discussion of this particular issue is beyond the scope of this chapter, it is nonetheless worth consider￾ing the origin of this knowledge in many systems. For the most part this knowledge is hand-coded: similarity tables and trees, such as the vacation ontology above, are made

11 Case-Based Recommendation Vacation Type Activi Relaxation Skiing Walking Beach Countryside Sim(skiing, walking)4~平 Sim(skiing, beach Fig. 11.6. A partial ontology of vacation types can be used as the basis for similarity judgments for non-numeric features available and codified by a domain knowledge expert. Similarly, importance weights might be assigned by the user at retrieval time or by the domain expert during sys- tem design. Hand-coding this knowledge is, of course, expensive and so increasingly researchers have begun to explore how machine learning techniques can be used to relieve these knowledge acquisition costs A number of researchers have looked at the issue of automatically learning the fea ture weights that are be used to influence the level of importance of different features during the case similarity calculations. Wettschereck and Aha [102], for example, de scribe an evaluation of a number of weight-learning algorithms that are knowledge poor, in the sense that they avoid the need for detailed domain knowledge to drive the learning process. They show how even these knowledge-poor techniques can result in significant improvements in case-based classification tasks and present a general frame- work for understanding and evaluating different weight-learning approaches; see also the work of [42, 81] for approaches to local weight-learning in CBR based on reinforce- Stahl [ 96] also looks at feature-weight learning but describes an alternative approac in which feedback is provided by a"similarity teacher"whose job it is to evaluate the ordering a given retrieval set. For example, in a recommender context a user may play the role of the similarity teacher because her selections can be interpreted as retrieval feedback; if our user selects product number 3 in the list of recommendations first then we can conclude that the correct ordering should have placed this product at the top of the list. Stahl,s learning algorithm attempts to minimise the average ordering error in retrieval sets. The work of Cohen et al. [25] looks at the related issue of learning to order items given feedback in the form of preference judgements. They describe technique for automatically learning a preference function to judge how advisable it to rank some item i ahead of item j, and go on to show how a set of items can then

11 Case-Based Recommendation 351 Fig. 11.6. A partial ontology of vacation types can be used as the basis for similarity judgments for non-numeric features. available and codified by a domain knowledge expert. Similarly, importance weights might be assigned by the user at retrieval time or by the domain expert during sys￾tem design. Hand-coding this knowledge is, of course, expensive and so increasingly researchers have begun to explore how machine learning techniques can be used to relieve these knowledge acquisition costs. A number of researchers have looked at the issue of automatically learning the fea￾ture weights that are be used to influence the level of importance of different features during the case similarity calculations. Wettschereck and Aha [102], for example, de￾scribe an evaluation of a number of weight-learning algorithms that are knowledge￾poor, in the sense that they avoid the need for detailed domain knowledge to drive the learning process. They show how even these knowledge-poor techniques can result in significant improvements in case-based classification tasks and present a general frame￾work for understanding and evaluating different weight-learning approaches; see also the work of [42, 81] for approaches to local weight-learning in CBR based on reinforce￾ment learning. Stahl [96] also looks at feature-weight learning but describes an alternative approach in which feedback is provided by a “similarity teacher” whose job it is to evaluate the ordering a given retrieval set. For example, in a recommender context a user may play the role of the similarity teacher because her selections can be interpreted as retrieval feedback; if our user selects product number 3 in the list of recommendations first then we can conclude that the correct ordering should have placed this product at the top of the list. Stahl’s learning algorithm attempts to minimise the average ordering error in retrieval sets. The work of Cohen et al. [25] looks at the related issue of learning to order items given feedback in the form of preference judgements. They describe a technique for automatically learning a preference function to judge how advisable it is to rank some item i ahead of item j, and go on to show how a set of items can then