A Survey on Conversational Recommender Systems

本文探讨了对话式推荐系统(CRS)如何通过多轮对话解决信息过载问题,支持用户偏好发掘及推荐解释等功能。CRS通过对话管理、用户建模及推荐引擎等组件实现智能推荐。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

A Survey on Conversational Recommender Systems

推荐系统用于解决用户寻找物品时遇到的信息过载问题。以往的推荐系统往往根据用户的历史行为对于要推荐的物品进行排序。交互式推荐系统(CRS)可以通过向用户提问提供更丰富的交互。

INTRODUCTION

推荐系统的成功伴随着AI的发展,在电商背景中,该系统主要作用是指出用户对一些潜在物品的兴趣。不仅帮助用户解决了信息过载的问题,还为商家带来了巨大的收益。
在很多实际应用中,推荐是一个一次性的过程——系统内部的监视器会根据用户的历史行为结合预定义的特定场景给出推荐。但是这样会带来一些问题:

  1. 有一些用户的偏好无法从历史交互中预测出来,尤其是在面对一些高卷入度的产品时(智能手机)
  2. 有些用户需求高度依赖于上下文语境,拥有很强的即时性
  3. 部分用户没有明显的偏好

CRS可以帮助解决以上挑战,该类系统支持面向用户的以任务为导向的多轮对话。通过对话可以引出具体且实时的用户偏好,提供对于物品建议的解释,根据用户反馈调整建议。CRS主要有基于模板和基于自然语言处理的两种方式。
基于模板的方式预定义并且没有歧义,但是会显得不自然以及限制了用户偏好的表达。基于自然语言处理的方式在近年得到了飞速发展,首先是自然语言处理方面技术的发展,其次还吸纳了聊天机器人的技术。
这些科技进步推动了CRS的发展,如今人们喜欢用机器学习的方法代替之前预定义的对话路径,但是如今的语音助手和聊天机器人和真实的推荐场景仍旧有差距。

METHODOLOGY

Characterization of Conversational Recommender Systems

CRS的宽泛定义:通过多轮对话使得用户达成推荐相关的目标的软件系统。CRS的主要特征是有明确的任务导向,主要是为用户提供推荐,也有诸如习得用户偏好、提供推荐的解释等任务。
CRS的多轮交互也是一个重要特征,这和那些仅仅支持问答或是提供一次性的问答类风格的产品具有很大不同。它可以通过state management追踪一些对话的历史和现在的状态来挖掘隐藏需求或是明确需求。
CRS没有规定输入输出的形式,可以是语音、文本、手势或按键。输出也不局限于语音或文本等等。
交互式推荐系统和交互式搜索系统非常相似,一个主要的区别是交互式推荐系统中心任务是理解用户的偏好和需求,对于用户之前的询问和动作要用更复杂的机制保持跟踪。

Conceptual Architecture of a CRS

交互式推荐系统的典型结构
上面的图片是交互式推荐系统的典型结构,有计算和知识两个部分。

Computational Elements

Dialogue Management System是交互式推荐系统的中心部分,主要任务是处理接收到的用户行为来更新对话状态和当前偏好文件以及决定下一步的行为。User Modeling System可以是一个独立的部分,尤其是在有一个长期用户偏好要被考虑或不被考虑的情况下。在一些情况中,当前偏好文件是隐含在对话系统中的。Recommendation and Reasoning Engine根据现有对话状态和偏好模型产生推荐集合。

Knowledge Elements

CRS中使用了许多不同种类的知识,Item Database代表了一些列供推荐的物品,有时会包括一些细节特征。Domain and Background Knowledge也经常被CRS使用,有很多种方法,将dialogue knowledge通过不同方式编码、预定义对话的状态、支持用户的目的和在不同状态之间转换。这些知识可以由系统设计者定义或是从别的资源和先前的交互自动学得。通常来说,领域和背景知识可以被所有computational elements使用

Research Method: Identifying Relevant Works

INTERACTION MODALITIES OF CRS

用户和CRS之间的交互不受限于自然语言的输入输出和特殊的设备。

Input and Output Modalities

现有论文主要基于两种形式的输入,还有一些是将这两种方法混合起来:

  1. 基于格式的结构化布局
  2. 基于自然语言

下面就是很多基于这两种方法或是混合方法的应用概述。

Application Environment

CRS既可以作为一个独立存在的应用也可以成为一个大型软件的一部分。前者推荐是其核心功能,例如移动导游、电商推荐等情景。后者CRS作为嵌入系统的一部分,推荐就只是系统众多功能的一部分,用户有事甚至无法感知到推荐的存在,例如语音助手。
CRS应用环境的另一方面就是支持的设备,由于目标设备的特征和功能会对CRS的建立产生影响。根据不同的设备特性需要设计不同的CRS。但CRS的使用并不局限于提到的设备,可以有很多替代方法,例如将CRS作为可以安装在商店交互墙上的应用;对餐厅的情景,建立一个可以运行在服务机器人上的CRS,使其可以明确用户对食物的偏好。

Interaction Initiative

交互式推荐系统的一个中心问题是谁来初始化对话,我们将其分为三类:

  1. 系统驱动
  2. 用户驱动
  3. 混合初始化

基于评判的系统主要使用系统驱动,有时使用混合初始化。在这些应用中,用户会被先询问偏好,然后就产生一个初始化得推荐。用户可以接着使用一系列预定义的或是动态生成的评判来重定义偏好。用户在这类应用中随着对话流的推进会有一些选择,他们可以选择接受推荐或是应用更多的评判,这些选择非常有限同事评判由系统产生。另一种大部分由系统驱动的应用是form-based interactive advisory systems,系统通过个性化的偏好引导对话获取足够的用户信息,在推荐初始化之后又,用户可以通过选择预定义的选项来影响对话例如询问解释或者是放松一些限制。
另外的用户驱动系统中,系统不扮演主动的角色,对话变成了一对对的“用户提问,系统回答”,这样的推荐模式就成为了典型的一次性问答,我们没有找到任何论文是这样完全由用户驱动而没有系统激活的。
这个结果非常令人振奋,因为每一个CRS都是以达成类似获取足够可靠用户偏好信息为目标。因此,几乎所有的方法都采用了混合初始化。技术上说,一个完全基于自然语言处理的的对话可以几乎由系统驱动,推荐过程为“系统问,用户响应”,但是用户或许会因为自己无法真正地参与到这个对话中而感到失望。

Discussion

用户和CRS的交互有多种方式,包括输入和输出的模式、支持的设备或是用户的参与度。现有的研究都有其优势和不足,针对不同的用户也有自己偏好的系统。随着越来越多的设备配备了CPU并且入网,我们看好CRS的未来发展。

KNOWLEDGE AND DATA BEHIND

根据选定的方法,CRS需要吸纳不同的知识和背景数据才可以发挥作用。显然,和任何的推荐系统一样必须要有关于推荐物品的信息。同时还需要有推荐的规则和限制,或者是机器学习所需要的背景数据。但是交互式推荐系统还依赖于额外种类的知识,例如对话中可能的状态、用于将自然语言推荐记录和转化的用于机器学习的数据。

Supported User Intents

CRS是用于解决上下文信息过滤和做出选择的问题的对话系统,因此在对话中要能够支持用户的特殊信息需求和和意图。在很多CRS中,支持用户的意图是被在系统建立之初被预定义且代表了很大一部分人工对背景知识的建模。尤其是基于NLP的方法,探测当前用户的意图并且选择系统的回应是系统的一个主要计算任务。
针对不同的CRS有很多不同的支持用户意图的集合,选择也依赖于应用领域。有一些意图在很多CRS中是相同的:
一些共通的用户意图
启动、重启或是结束对话。基于NLP的CRS中,系统和用户都可以初始化对话,在用户驱动的对话中,在推荐前可能需要做一个推荐要求来开始交互。在这种情况下的一个典型困难是在chit-chat中识别这类要求。一旦推荐对话开始了想让用户在从头开始就不太现实。之前的研究表明在单纯的对话中发现用户意图的概率是5.2%,而在加入了推荐要求后概率变味了36.4%。在对话的最后,用户可能发现推荐是有用的通过一些类似消费的行为来证实,也有可能发现推荐没用。在其他的情况中,CRS必须对于意图做出一些反应,例如将用户重定向至购物车或是说再见。
chit-chat。很多NLP系统在对话中支持chit-chat。接近80%有记录的用户语料都考虑了chit-chat。这说明了支持chit-chat可以是一个吸引用户的好办法。chit-chat也可以降低用户的不满意度,及时这在对话中和最终的交互目标并没有关系。
Preference Elicitation。CRS的一个关键任务是理解用户的偏好。用户可以通过不同的方式提供偏好信息。在对话的初始阶段,用户可能会明确一些想要的物品的特征甚至提供严格的过滤限制。这个过程叫做“give criteria”。在之后的阶段,用户可能想修改之前的陈述的偏好。值得一提的是一些作者也考虑到了answering——系统提供问题或是限制条件的建议——作为在偏好清晰化中的对话意图。在基于NLP的系统中用户的回应可能很模糊,这时系统消除歧义的能力就显得尤为重要。
在过程的更后面阶段,在推荐由系统做出初始化之后偏好可以从用户做出的不同方式的陈述中得到。例如在基于评判的方法中,用户可以增加额外的限制如果选择集合太大,放宽一些之前的陈述,或者说明他们已经这到这些物品。通常来说,一个西永也允许用户检查、修改、删除当前的profile。
通过分析一个语音控制的电影推荐原型的交互记录,发现有41.1%的用户在一些阶段想要重新定义他们陈述的初始偏好。尤其是在不满意系统响应中,一些用户或许会有拒绝推荐或是重新陈述偏好的意图。但是这只在1.5%的交互中发生。
Obtaining Recommendations and Explanations。用户想要询问推荐系统和关于物品的额外信息会有很多方式。在对话的开始阶段询问推荐是经常发生的,但是这一事件也会在用户修改了偏好之后发生。如果当前显示的推荐结果没让用户满意,用户也许会让系统显示更多的选项或者询问一些相似项目的比较。对于每一个物品,用户也许想了解更多的细节或是寻求一个解释——为什么这个物品被推荐了。最后,一个可调整的寻求推荐形式就变成了询问系统XXX物品怎么样。

User Modeling

通过交互启发式地得到用户当前偏好或是需求以及限制是CRS的另一个中心任务。像之前讨论的,这可以通过不同的方式和多种多样的支持用户表达他们想要的物品的方式来实现。需要的偏好一般来说记录在user profile中,基于更远的推论依赖于独立物品的关联。这种启发式模型有两种主要表达偏好的方式:

  1. 偏好表达或预测独立的物品,例如评分、喜欢和不喜欢的陈述、隐含的反馈信号。
  2. 根据独立物品的方面的偏好。这些方面可以喝物品的特征或是需要的功能相关

对于后一种方法,CRS的目标有时被称为填补缝隙,推荐系统为预定义的方面寻找内容。有时,也是偏好的有时,必须活着希望是相关的。从结构化或非结构化的文本中减少可能的方面是被采用的,方面的集合经常基于主要的专业知识被手动的建立。更有甚者,为了让方面符合功能需求,额外的知识需要被编码以符合可推荐物品的需要。例如一个用户在交互式相机推荐中,询问自己要拍摄什么种类的相片,基于限制的系统接着会决定相机是否符合这个目的。
除了这种在进行阶段被建立的短暂用户模型,一些方法也保持了长期的偏好文件。在评判方法中,举个例子,系统想要从多个阶段中导出长期且更稳定的偏好。在基于内容的推荐方法中,基于用户过去的偏好的概率模型被应用了。通常来说,当推荐模型基于两种模型时(长期和短期),需要考虑两个模型的相关重要性。
最后,也有一些方法试图利用关于用户社交的偏好信息,尤其是在冷启动的情景下。 如果对用户偏好一无所知或是知之甚少,一个通用的策略是推荐流行的物品,物品的流行度可以考用户的评分、评论、销售量来决定。收集到的关于流行物品的反馈可以在之后被用来定义用户模型。

Dialogue States

为了支持一个多轮目标导向的对话,CRS必须要实现一个合适的方法来跟踪对话的状态用以决定下一步对话行为。在很多CRS的实现中尤其是基于知识的方法,对话管理器建立在有限状态机的基础上,不仅定义了可能的状态还允许不同状态之间的转换。在Advisor Suite框架中,整个推荐逻辑包括了在图像编辑建立的对话流。
在这里插入图片描述
上图是一张对话模型的简略示意图。包括了一系列对话步骤被用于获取用户偏好的问题,特殊对话状态用于系统表示结果,提供解释或暗示,展示在不同候选物品间的比较。在设计的时候可能的转变就被定义好了,但是具体路径的选择是根据选择的规则在对话中动态产生的。另一个例子是一个旅游推荐系统基于状态集合和可能的转换。在那种情况下,运行时的状态转换并不是被手动建立的决定规则所约束,但是是通过用强化学习技术学习到的数据,一个目标是最小化需要的交互步数。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值