【对话推荐系统综述】A Survey on Conversational Recommender Systems

文章信息：

发表于：ACM Computing Surveys 2021

原文链接：https://arxiv.org/abs/2004.00646

Abstract

推荐系统是一类软件应用程序，旨在帮助用户在信息过载的情况下找到感兴趣的项目。当前的研究通常假设一种一次性交互范式，即根据过去观察到的用户行为来估计其偏好，并通过展示一个排序的建议列表作为主要的、单向的用户交互形式。对话式推荐系统（Conversational Recommender Systems, CRS）则采取了不同的方法，支持更丰富的交互方式。这些交互可以帮助改进偏好获取过程，允许用户对推荐提出问题并给予反馈。近年来，对话式推荐系统的兴趣显著增加。这一发展主要归因于自然语言处理领域的显著进步、新型语音控制家庭助理的出现以及聊天机器人技术的广泛应用。

本文对现有的对话式推荐方法进行了详细的综述。我们从多个维度对这些方法进行分类，例如，所支持的用户意图或背后使用的知识。此外，我们还讨论了技术方法，回顾了对话式推荐系统的评估方式，并最终指出了一些值得未来进一步研究的研究空白。

1 INTRODUCTION

推荐系统是人工智能在实践中最为显著的成功案例之一。通常，这类系统的主要任务是指引用户找到潜在感兴趣的项目，例如在电子商务网站的背景下。通过这种方式，它们不仅帮助用户在信息过载的情况下做出选择[126]，还能显著提升服务提供商的商业成功[57]。

在许多实际应用中，推荐是一个一次性交互过程。通常情况下，底层系统会长期监控用户的行为，然后在预定义的导航情境中（例如用户登录服务时）呈现一组量身定制的推荐。尽管这种方法在各个领域中普遍且有用，但它可能存在一些潜在的局限性。例如，在某些应用场景中，用户的偏好无法从他们过去的交互中可靠地估计出来。这种情况在高参与度产品（例如推荐智能手机时）中尤为常见，甚至可能完全没有过去的观察数据。此外，推荐内容的确定可能高度依赖于上下文，而自动确定用户的当前情境或需求可能非常困难。最后，另一个常见的假设是用户在访问网站时已经明确了自己的偏好。然而，事实未必如此。用户可能只在决策过程中构建他们的偏好[152]，当他们意识到选项的范围时。在某些情况下，用户可能在与推荐系统交互的过程中才逐渐了解领域和可用的选项[154]。

对话式推荐系统（Conversational Recommender Systems, CRS）的潜力在于它们能够帮助解决许多上述挑战。简而言之，这类系统的一般理念是支持与用户进行任务导向的多轮对话。在这样的对话过程中，系统可以获取用户详细且当前的偏好，为推荐项目提供解释，或者处理用户对推荐内容的反馈。鉴于这类系统的显著潜力，对话式推荐系统的研究已有一定的传统。早在20世纪70年代末，Rich [127]就设想了一种计算机化的图书管理员，通过以自然语言交互式地向用户提问其个性和偏好来提供阅读建议。除了基于自然语言处理（NLP）的界面外，多年来还提出了多种基于表单的用户界面1。在对话式推荐系统中，较早的交互方法之一是“批评式推荐”，这种方法早在1982年就被提出，作为数据库领域中查询重构的一种手段[144]。在批评式推荐方法中，用户很快会在对话中收到推荐，然后可以对推荐应用预定义的批评，例如（“价格更低”）[15, 49]。

基于表单的方法通常具有吸引力，因为用户可用的操作是预定义的且明确的。然而，这种对话可能显得不自然，用户可能会感到在表达偏好时受到限制。另一方面，基于自然语言处理的方法长期以来受到现有技术的限制，例如在处理语音命令时。然而，近年来语言技术取得了重大进展。因此，我们现在习惯于向智能手机和数字家庭助理发出语音命令，这些设备的识别准确率已达到令人印象深刻的水平。与此同时，我们观察到聊天机器人技术近年来迅速普及。无论是简单的还是更复杂的聊天机器人，通常都能够处理自然语言，并且如今广泛应用于各个领域，例如处理客户服务请求。

这些技术进步在过去几年中引发了对对话式推荐系统（CRS）的日益关注。与许多早期方法相比，我们观察到当今的技术提案更多地基于机器学习技术，而不是遵循预定义的对话路径。然而，与支持真正对话式推荐场景所需的理想能力相比，当今的语音助手和聊天机器人的能力仍存在一定差距[117]，尤其是在系统为语音控制时[161, 165]。

本文从典型对话式推荐系统概念架构的常见构建模块出发，回顾了相关文献。具体而言，在第二部分提供了对话式推荐系统的定义和概念架构后，我们讨论了

（i）对话式推荐系统的交互模式（第三部分），

（ii）它们所基于的知识和数据（第四部分），以及

（iii）在典型对话式推荐系统中需要完成的计算任务（第五部分）。

随后，我们探讨了对话式推荐系统的评估方法（第六部分），并最终展望了未来的研究方向。

2 DEFINITIONS AND RESEARCH METHODOLOGY

在本节中，我们讨论了与本研究相关的前期准备。首先，我们提供了对话式推荐系统（CRS）的一般特征和概念模型。其次，我们讨论了我们的研究方法论。

2.1 Characterization of Conversational Recommender Systems

在文献中，关于什么是对话式推荐系统（CRS）并没有一个广泛认可的定义。在本研究中，我们采用以下定义。

Definition 2.1 (Conversational Recommender System–CRS).

对话式推荐系统（CRS）是一种通过多轮对话支持用户实现推荐相关目标的软件系统。

对话式推荐系统（CRS）的一个基本特征是其任务导向性，即它们支持与推荐相关的特定任务和目标。系统的主要任务是向用户提供推荐，其目标是支持用户的决策过程或帮助他们找到相关信息。对话式推荐系统的附加任务包括获取用户偏好或提供解释。这种特定的任务导向性将对话式推荐系统与其他基于对话的系统区分开来，例如早期的ELIZA系统[158]或类似的聊天机器人系统[151]。

根据我们的定义，对话式推荐系统（CRS）的另一个主要特征是支持多轮对话式交互。这与仅支持问答（Q&A工具）的系统形成对比。提供一次性问答式推荐是诸如苹果的Siri等个人数字助理及其类似产品的常见功能。虽然这些系统如今已经能够可靠地响应推荐请求，例如推荐一家餐厅，但它们往往难以维持多轮对话。因此，对话式推荐系统显式或隐式地实现了某种形式的对话状态管理，以跟踪对话历史和当前状态。

需要注意的是，我们的定义并未对输入和输出的形式做出任何假设。对话式推荐系统（CRS）可以是语音控制的，可以接受文本输入，也可以通过表单字段、按钮甚至手势获取输入。同样，输出形式也不受限制，可以是语音、文本或多媒体内容。此外，定义中也没有对谁主导对话做出假设。

总体而言，对话式推荐与对话式搜索[115]有许多相似之处。在底层任务方面，搜索和推荐的共同点在于其主要任务是根据对象的假设相关性对其进行排序，无论是针对给定查询（搜索）还是用户偏好（推荐）。此外，在对话部分，如果支持自然语言交互，两种系统都需要解释用户话语并消除用户意图的歧义。然而，在对话式搜索系统中，通常假设交互基于“书面或口头形式”[115]，而在我们对对话式推荐系统的定义中，各种类型的输入形式都是可能的。总体而言，（个性化）对话式搜索和推荐系统之间的界限常常显得模糊，参见[86, 139, 172]，特别是因为通常采用类似的技术方法。在本综述中，我们仅限于明确将推荐作为其目标问题之一的研究。

2.2 Conceptual Architecture of a CRS

在过去二十年中，提出了多种构建对话式推荐系统（CRS）的技术方法。这些解决方案的技术架构的具体细节取决于系统的功能，例如是否支持语音输入。尽管如此，仍然可以识别出此类架构中一些典型的互操作概念组件，如图1所示。

Computational Elements.
此类架构中的一个核心部分通常是对话管理系统（在某些系统中也称为“状态跟踪器”或类似名称）。该组件驱动流程。它接收处理后的输入，例如识别的意图、实体和偏好，并相应地更新对话状态和用户模型。之后，通过使用推荐和推理引擎以及背景知识，它确定下一步操作，并将推荐列表、解释或问题等适当内容返回给输出生成组件。

User Modeling System

用户建模系统可以是一个独立的组件，特别是当需要考虑长期用户偏好时，或者也可以不是。在某些情况下，当前的偏好配置文件隐式地成为对话系统的一部分。推荐和推理引擎负责根据当前的对话状态和偏好模型检索一组推荐。该组件还可能实现其他复杂的推理功能，例如生成解释或计算查询放松（见后文）。除了这些核心组件外，典型的对话式推荐系统架构还包括输入和输出处理模块。例如，这些模块可以包括语音到文本转换和语音生成。在输入侧——特别是在自然语言输入的情况下——通常还支持其他任务，包括意图检测和命名实体识别[66, 99]，以识别用户话语中的意图和实体（例如项目的属性）。

Knowledge Elements.

对话式推荐系统（CRS）使用各种类型的知识。项目数据库是几乎所有解决方案中都存在的，代表可推荐项目的集合，有时还包括其属性的详细信息。除此之外，对话式推荐系统通常还利用不同类型的领域和背景知识。许多方法以不同方式显式编码对话知识，例如以预定义对话状态、支持的用户意图以及状态之间可能的转换的形式。这种知识可以是通用的，也可以是特定于某个领域的。此外，知识可以由系统设计者编码，也可以从其他来源或先前的交互中自动学习。学习方法的典型例子是那些使用机器学习从记录的对话语料库中构建统计模型的方法。通常，领域和背景知识可以被所有计算元素使用。输入处理可能需要关于要识别的实体的信息或关于预定义意图的知识。用户建模组件可能基于对某些项目特征的估计兴趣权重，而推理引擎可能使用显式推理知识来推导出合适的推荐集。

2.3 Research Method: Identifying Relevant Works

我们采用了一种半系统化的方法来识别相关论文。首先，我们使用预定义的搜索字符串（如“对话式推荐系统”、“交互式推荐”、“咨询系统”或“聊天机器人推荐”）查询了多个数字图书馆。然后，根据标题和摘要手动检查返回的论文的相关性。被认为相关的论文被详细阅读，如果被认为在本文的范围内，则作为滚雪球程序的起点。总体而言，论文选择过程筛选出了121篇关于对话式推荐系统的论文，我们在本研究中对其进行了考虑。从这些论文的类型来看，大多数工作描述了对话式推荐系统架构中某个计算组件的技术提案。较小一部分论文描述了演示系统。另一小部分论文是分析性的，例如，它们回顾了对话式推荐系统的某些一般特征。

一般而言，我们仅纳入了符合上述对话式推荐系统（CRS）定义的论文。因此，我们没有纳入讨论一次性或多步问答系统的论文[133, 166]，即使问题或任务涉及推荐。我们也没有考虑非任务导向的通用对话系统（如聊天机器人系统），或仅支持查询-响应交互过程的系统（如没有进一步对话步骤的搜索引擎），例如[31]。此外，我们没有纳入任务导向但不涉及推荐任务的对话系统，例如[159]和[76]中提出的端到端学习方法，这些方法专注于餐厅搜索和电影票预订。此外，我们排除了[50]或[174]等使用“交互式推荐”一词的论文，这些论文主要涉及系统如何应对用户兴趣随时间的变化，但并未设计为支持与用户的对话。其他论文如[138]或[174]主要关注为冷启动用户获取初始评分集的策略。虽然这些论文可以被视为支持交互过程，但仅有一种交互类型，且大多局限于用户画像构建阶段。最后，还有一些论文为推荐系统用户提供了微调推荐的机制，有时被称为“用户控制”[61]。这些论文（例如[163]）原则上支持某些对话式推荐系统中常见的用户操作，例如对推荐提供反馈。然而，这些方法的交互风格并非与系统的对话。

3 INTERACTION MODALITIES OF CRS

近年来，对话式推荐系统（CRS）的兴趣激增，既得益于自然语言处理（NLP）的发展，也得益于宽带移动互联网接入以及智能手机和家庭助理等新设备的技术进步。然而，我们对文献的回顾表明，用户与对话式推荐系统之间的交互既不局限于自然语言输入和输出，也不局限于特定设备。

3.1 Input and Output Modalities

大多数被调查的论文明确或隐含地支持两种主要的输入和输出形式，无论是作为唯一的模式还是以混合方式结合：

• 基于表单和结构化布局，类似于传统的基于网页（桌面）应用程序。
• 基于自然语言，无论是书面形式还是口头形式。

完全基于表单（包括按钮、单选按钮等）和结构化文本输出的方法在几乎所有基于批评的推荐方法中都很常见（除了[47]），例如[7, 39, 52, 89, 123]，以及基于网页的交互式咨询解决方案中，例如[41, 55, 60]。在此类应用程序中，用户通常遵循预定义的对话路径，并通过填写表单或从预定义选项中进行选择来与应用程序交互。最终输出通常是以选项列表形式呈现的结构化视觉表示。

另一方面，完全基于自然语言交互的方法包括任务导向的对话系统，如[127]的早期提案，[109]提出的解释感知对话系统，以及更近期的基于（深度）学习的方法，例如[46, 48, 77]。仅支持语音文本的方法通常在智能扬声器（如亚马逊Alexa或谷歌Home）上实现，例如[4, 36]。与基于表单的方法相比，这些解决方案通常在对话中提供更大的灵活性，有时还支持闲聊和混合主动对话。然而，主要挑战可能在于理解用户的话语和识别其意图。此外，推荐的呈现也可能很困难，特别是在需要同时提供多个选项时。

因此，将自然语言与其他模式结合的混合方法并不少见。例如，支持书面自然语言对话的系统通常依赖基于列表或其他视觉方法来呈现其结果[73, 172]。另一方面，[167]中提出的工作支持混合视觉/自然语言交互机制，其中推荐以视觉方式显示，用户可以通过自然语言以类似批评的形式对某些特征提供反馈。还有一些系统支持语音输入，但以文本形式呈现推荐[47, 142]，因为通过口语同时呈现多个推荐可能会让用户感到不知所措。最后，聊天机器人应用程序通常将自然语言输入和输出与结构化表单元素（例如按钮）和推荐的视觉结构化表示相结合[53, 62, 100, 114]。

除了书面或口头语言以及填写表单外，还可以找到一些其他替代的和特定于应用程序的输入和输出模式。例如，[150]中提出的对话系统支持多种类型的输入，包括地理地图上的视觉输入、如缩放等笔势或手写输入。[18]中提出的工作还尝试处理非语言输入，如身体姿势、手势、面部表情以及语音韵律，以估计用户的情绪和态度，从而获取隐式反馈和偏好。

在输出方面，几种方法使用交互式地理地图，通常作为多模式输出策略的一部分[5, 39, 73, 150]。基于地图的方法的适用性限于某些应用领域，例如旅游和观光，但可以帮助克服与对话系统用户体验相关的各种挑战[125]。在文献中，使用具身对话代理（ECA）[19]作为附加输出机制也并不少见[41, 52]，因为假设类人化头像具有普遍的说服潜力[2, 38]。各种因素可以影响此类ECA的有效性。例如，在[43]中，作者分析了在基于对话的推荐系统背景下，非语言行为（如面部表情）对ECA有效性的影响。然而，关于在推荐系统背景下使用不同ECA变体的具体效果的研究通常很少。

最后，存在一些用户在与推荐系统交互时使用虚拟三维空间的作品。在[33, 34]中，作者描述了一个虚拟购物环境，用户与基于批评的推荐系统交互，并且可以与其他用户协作。支持群体决策也是[1]中提出的工作的目标。然而，在这项工作中，不支持3D可视化，并且工作的重点主要是使由推荐系统支持的用户群体之间的对话成为可能。图2提供了文献中常见的输入和输出模式的概述。

3.2 Application Environment

Stand-alone and Embedded Applications.

对话式推荐系统（CRS）既可以是独立应用程序，也可以是更大软件解决方案的一部分。在第一种情况下，推荐是系统的核心功能。此类应用的例子包括[7, 60, 86]中提出的移动旅游指南，[41, 58]中讨论的交互式电子商务咨询系统，或早期的FindMe浏览和购物系统[14, 15]。在第二种情况下，即嵌入式应用程序，对话式推荐系统并不（完全）独立存在。通常，对话式推荐系统以聊天机器人的形式实现，嵌入在电子商务解决方案[32, 164]或其他类型的网络门户[21]中。在某些情况下，对话式推荐系统也是多模式2D或3D用户体验的一部分，如[33]和[43]中所示。在这种情况下，一个特殊情况是在基于语音的家庭助手（智能扬声器）上使用对话式推荐系统[4, 36]。在这种设置中，提供推荐只是设备众多功能中的一项。因此，用户可能实际上并不将系统视为主要是推荐系统。

Supported Devices.

关于对话式推荐系统（CRS）应用环境的一个正交方面是所支持的设备。这一点尤为重要，因为目标设备的具体功能和特性对构建对话式推荐系统时的设计选择有重大影响。例如，提到的智能扬声器应用程序专门为通常仅支持基于语音交互的硬件设备设计。这可能会带来特定的挑战，例如在确定用户意图或需要向用户呈现大量替代方案时。另一方面，与聊天机器人应用程序的交互通常不依赖于特定的硬件设备。通常，它们要么设计为网络应用程序，要么设计为智能手机和平板电脑应用程序。然而，所使用的通信模式的选择仍然可能取决于设备特性。在小型智能手机屏幕上打字可能很繁琐，而有限的屏幕空间通常需要开发定制的用户界面。

对话式推荐系统（CRS）的适用性并不限于上述设备。例如，在[18, 37]中研究了替代方法。这里的想法是将对话式推荐系统实现为安装在实体店中的交互墙上的应用程序。此外，还使用摄像头来监控和解释用户的非语言交流行为，特别是面部表情和手势。[170]中设想了一个替代的现场环境。这里的最终目标是构建一个运行在服务机器人上的对话式推荐系统，在这种情况下，该机器人能够在餐厅中获取顾客的食品偏好。[83]中描绘了另一个应用场景，即未来的车载推荐系统。鉴于驾驶场景中的特定情况，通常建议使用语音技术[22]，这几乎自然会导致对话式推荐方法，例如用于导航或娱乐等与驾驶相关的方面[8, 9]。

3.3 Interaction Initiative

对于大多数对话系统来说，一个核心的设计问题是谁在对话中占据主导地位。传统上，我们可以区分为（i）系统驱动，（ii）用户驱动，以及（iii）混合主导系统。当主要将对话式推荐系统（CRS）视为对话系统时，这种分类原则上也可以应用，但分类并不总是完全清晰。

基于批评的系统通常被认为主要是系统驱动的，有时是混合主导的，例如在[148]中。在此类应用程序中，通常首先询问用户的偏好，例如使用表单，然后呈现初始推荐。然后，用户可以使用一组预定义或动态确定的批评来进一步细化他们的偏好。虽然在此类应用程序中用户对对话流程有一些选择，例如他们可以决定接受推荐或进一步应用批评，但这些选择通常非常有限，并且可用的批评由系统决定。另一类主要是系统驱动的应用程序是[41]中讨论的基于表单的交互式咨询系统。在这里，系统引导用户通过个性化的偏好获取对话，直到对用户有足够的了解。只有在初始推荐显示后，用户才能通过从预定义选项中选择来影响对话，例如请求解释或放松一些约束。

另一个极端是用户驱动的系统，其中系统不采取主动角色。因此，生成的对话由“用户提问，系统响应”对组成，我们是否会将这种交换称为对话式推荐值得怀疑。这种对话模式在一次性问答、搜索和推荐系统中相当典型，这些系统不在我们调查的范围内。因此，在为本研究考虑的相关论文中，我们没有找到任何旨在构建完全用户驱动系统的论文，其中系统从不主动参与对话，例如，系统从不提问。在这种情况下，一个特殊情况是[82]中提出的推荐系统，该系统监控正在进行的群聊，并偶尔根据观察到的通信向群组提出建议。

这一观察并不令人惊讶，因为每个对话式推荐系统（CRS）都是任务导向的系统，旨在实现诸如获取足够可靠的用户偏好信息等目标。因此，文献中的几乎所有方法都是混合主导系统，尽管系统指导的程度不同。例如，典型的聊天机器人应用程序通常通过一系列问题引导用户，并提供预定义的答案选项（使用表单和按钮），同时允许他们以自然语言输入陈述。在完全基于自然语言处理（NLP）的界面中，用户通常有更多的自由来影响对话的继续。然而，即使在这些情况下，系统通常也有一些议程来推动对话。

从技术上讲，即使完全基于NLP的对话也几乎可以完全由系统驱动，并且主要依赖于“系统提问，用户回答”[172]的对话模式。然而，当用户发现他们永远无法主动参与对话时，例如通过提出澄清问题或对系统问题的解释，提供自然语言用户界面可能会让用户感到失望。

3.4 Discussion

设计用户与对话式推荐系统（CRS）交互的方式多种多样，例如在输入和输出模式、支持的设备或用户控制水平方面。然而，在大多数调查的论文中，这些设计选择很少被讨论。一个原因是，在许多情况下，提出的技术方法大多独立于交互模式，例如，当工作是关于确定下一个向用户提问的策略时。在其他情况下，模式由给定的研究问题预先确定，例如如何在移动设备上构建对话式推荐系统。

因此，似乎需要更多的研究来理解如何在这些方面做出良好的设计选择，以及每个设计选择的影响和局限性。例如，关于选择的输入和输出形式，与基于表单的输入相比，自然语言交互是否总是使推荐更高效或更有效并不总是完全清楚。纯自然语言界面原则上提供了以更自然的方式获取偏好的机会。然而，这些界面也有其局限性。例如，语音识别器的准确性可能对系统的可用性产生重大影响。此外，一些用户可能更熟悉并感觉更舒适于更传统的交互机制（表单和按钮）。根据[54]中的研究，自然语言界面和按钮的混合导致了最佳的用户体验。此外，在[102]中，发现在需要消除歧义的情况下，即当用户必须在多个替代方案中进行选择时，混合交互模式（带有按钮的NLP界面）可以使用户的任务更容易。总体而言，虽然在某些情况下，模式的选择通过设备预先确定，但找到交互模式的最佳组合仍然具有挑战性，特别是因为个人用户偏好可能在这里发挥作用。

还需要更多的研究来了解用户需要多少对话灵活性，或者在特定应用中系统提供的主动指导有多受欢迎。此外，尽管近年来基于语言的对话，特别是基于语音的对话变得更加流行，但某些局限性仍然存在。例如，在使用语音输出时，如何描述一组推荐并不总是很清楚。在大多数情况下，读出多个推荐似乎不切实际，可能需要我们称之为“推荐摘要”的东西。

尽管存在这些潜在的当前局限性，我们预计未来对话式推荐系统（CRS）将在许多新机会中得到应用。随着技术的不断发展，越来越多的设备和机器配备了CPU并连接到互联网。如上所述，店内互动墙、服务机器人和车载推荐系统是当今已经在追求的愿景的例子。然而，这些新应用也将带来它们自己的一般挑战（例如，隐私考虑、技术接受度方面）和特定应用的挑战（例如，车载环境中的安全考虑）。

4 UNDERLYING KNOWLEDGE AND DATA

根据选择的技术方法，对话式推荐系统（CRS）需要整合各种类型的知识和背景数据才能运行。显然，与任何推荐系统一样，必须有关于可推荐项目的信息。同样，推荐的生成要么基于显式知识，例如推荐规则或约束，要么基于在某些背景数据上训练的机器学习模型。然而，对话系统通常依赖于关于CRS支持的用户意图、对话中的可能状态或用于训练机器学习模型的记录和转录的自然语言推荐对话等额外类型的知识。在接下来的部分中，我们概述了文献中用于构建CRS的不同类型的知识和数据。

4.1 User Intents

对话式推荐系统（CRS）是设计用于在信息过滤和决策背景下服务于非常特定目的的对话系统。因此，它们必须支持用户在此类对话中可能出现的特定信息需求和意图。在许多CRS中，系统支持的用户意图集是预定义的，并代表了系统构建所依赖的手工工程背景知识的主要部分。特别是在基于自然语言处理（NLP）的方法中，检测当前用户的意图并选择系统的响应是系统的主要计算任务之一，参见第5节。因此，在本节中，我们将主要关注基于NLP的系统。

系统支持的用户意图集在文献中找到的不同CRS中各不相同，支持哪些意图的选择最终取决于应用领域的需求。然而，虽然系统支持的意图子集有时也特定于应用程序，但有许多意图在许多CRS中是常见的。在表1中，我们提供了在我们文献综述中找到的与领域无关的用户意图的高级概述。表1中意图的顺序大致遵循典型推荐对话的流程。此概述还旨在作为CRS设计者的工具，以检查他们当前系统在潜在用户需求方面是否存在任何未被良好支持的空白。

关于什么是相关用户意图的研究普遍稀少，我们只找到了11篇明确讨论用户意图的论文。在这11篇论文中，只有少数，例如参见[16, 100, 164]，考虑了表1中显示的大多数与领域无关的意图。其他如[65, 105, 142]只讨论了其中的某些子集。还有一组论文专注于群体推荐背景下的非常特定于应用程序的意图[1, 103]。

Starting, re-starting, and ending the dialogue.

在基于自然语言处理（NLP）的对话式推荐系统（CRS）中，系统或用户都可以启动对话。在用户驱动的对话中，推荐寻求者可能会明确请求帮助[100]或提出推荐请求[162]以开始互动。在这种情况下，当对话以闲聊开始时，识别此类请求是一个典型的困难。一旦推荐对话继续进行，用户想要重新开始，即从头开始会话并“重置他们的个人资料”[100]并不罕见。先前的研究发现，在5.2%的对话中发现了这种意图[16]，或者在对话中36.4%的用户有这种意图[65]。最后，在对话结束时，用户要么发现推荐有用并以某种形式接受它（例如通过购买或消费项目），要么没有。无论哪种情况，CRS都必须以某种形式对意图做出反应，例如将用户重定向到购物篮，或者说再见。

Chit-chat.

许多基于自然语言处理（NLP）的系统在对话中支持闲聊。在[164]的研究中，近80%的记录用户话语被认为是闲聊。这一数字表明，支持闲聊对话可能是创造引人入胜的用户体验的有价值手段。此外，[164]中的研究表明，闲聊还可以帮助减少用户的不满，即使对话的这一部分与实现互动目标无关。

Preference Elicitation.

理解用户的偏好是任何对话式推荐系统（CRS）的关键任务。用户可以通过不同的方式提供偏好信息。在对话的初始阶段，用户可能会指定她或他感兴趣的项目的某些期望特征，甚至提供严格的过滤约束。在[105]中，此过程被称为“给出标准”。然而，在后期阶段，用户可能还希望修改先前陈述的偏好。请注意，一些作者还将回答——对系统提供的问题或约束建议[25, 145]——视为偏好获取过程中的对话意图[156]。由于在基于自然语言处理（NLP）的系统中，用户可能以任意方式回应，因此系统明确区分用户的回答与其他话语显然很重要。然而，这种“回答”意图与此处讨论的其他意图不同，因为该意图是对系统提问的回应。

同样在流程后期，在系统做出初始推荐后，用户可以通过不同方式陈述偏好。在基于批评的方法中，例如，如果选择集太大，用户可以添加额外的约束，放松一些先前陈述的约束，或者陈述他们已经知道该项目[56, 123, 142]。通常，系统还可能允许用户检查、修改和删除当前个人资料（支持“显示个人资料”意图）[100]。通过分析原型语音控制电影推荐器的交互日志，例如在[65]中，作者发现许多用户（41.1%）在某些阶段试图细化他们最初陈述的偏好。特别是在系统响应不满意的情况下，一些用户可能还会有“拒绝”[156]推荐或“重新陈述”他们的偏好的意图。然而，在[16]中提出的研究中，这种情况仅发生在1.5%的交互中。

Obtaining Recommendations and Explanations.

用户可以通过多种方式请求推荐和有关项目的附加信息。请求推荐通常发生在对话的最开始，但此事件也可能在用户修改偏好后发生。如果当前显示的选项列表不令人满意，用户还可能要求系统“显示更多”选项[16]或请求类似项目进行比较。对于每个项目，用户可能希望了解更多详细信息或请求解释，例如为什么推荐它[100]。最后，请求推荐的另一种形式是询问系统对某个项目的意见（“怎么样”），参见例如[164]。

4.2 User Modeling

交互式获取用户当前偏好或需求和约束是对话式推荐系统（CRS）的另一项核心任务。如上所述，这可以通过不同的模式实现，并支持用户以各种方式表达他们的需求。获取的偏好通常以显式形式记录在用户档案中，基于此可以进一步推断各个项目的相关性。在这种显式模型中，表示偏好信息主要有两种方式：

• 关于单个项目的偏好表达或估计，例如评分、喜欢和不喜欢陈述，或隐式反馈信号。例如，在[39]中，用户最初会看到一些旅游目的地，并被询问哪些符合他们的偏好。
• 关于单个项目方面的偏好。这些方面可以涉及项目属性（例如电影的类型）或所需的功能。

对于后一类方法，对话式推荐系统（CRS）的目标有时被称为“槽填充”，即推荐系统试图为一组预定义的方面获取值。有时，偏好强度（例如必须或希望）也可能相关[123]。虽然文献中提出了从结构化和非结构化文本文档中挖掘可能方面的不同方法[157]，但方面集通常基于领域专业知识手工设计。此外，如果方面涉及功能需求，如[55, 160]中所述，则必须在系统中编码额外的知识以将这些需求与可推荐的项目匹配。例如，在[55]中，交互式相机推荐器的用户会被询问她或他想要拍摄的照片类型（例如体育摄影），然后使用基于约束的系统来确定适合此目的的相机。

最后，存在一些不假设存在一组工程化项目特征的工作。例如，在[119]中，提出了一种偏好获取方法，用户反复指定对项目的偏好，然后系统根据非结构化特征（如关键词或标签）找到相似的项目。同样，[81, 84]和[149]中提出的偏好获取方法使用了其他类型的非工程化特征（标签、关键短语或潜在表示）。

除了在会话期间构建的这种临时用户模型外，文献中的一些方法还维护长期偏好档案[4, 123, 142, 154]。例如，在[123]中的批评方法中，系统尝试从多个会话中推导出长期且被认为更稳定的偏好（例如，餐厅中的无烟房间）。在[142]中采用的内容推荐方法中，基于过去用户对项目的偏好维护了一个概率模型。通常，基于两种模型（长期和短期）进行推荐时的关键问题是确定各个模型的相对重要性。迄今为止尚未探索的一个选项可能是考虑上下文因素，如季节性方面、用户的位置或一天中的时间。

最后，还有一些方法尝试利用用户社区的集体偏好信息，特别是在冷启动情况下[101]。如果对用户的偏好知之甚少或一无所知，常见的策略是推荐受欢迎的项目，其中项目受欢迎程度可以根据用户评分、评论或过去的销售数量确定，如[47]中所述。然后，可以使用对这些受欢迎项目的反馈来进一步细化用户模型。

4.3 Dialogue States

为了能够支持与用户进行多轮、目标导向的对话，对话式推荐系统（CRS）必须实施适当的手段来跟踪对话状态，以决定下一个对话动作，即下一个行动。在许多CRS实现中，特别是在基于知识的方法中，对话管理基于有限状态机，它不仅定义了可能的状态，还定义了状态之间的允许转换[85, 86, 153, 155]。例如，在Advisor Suite框架[55, 58]中，包括对话流程在内的整个推荐逻辑都借助图形编辑器进行建模。

图3展示了此类对话模型的示意性概述。它由（i）通过问题获取用户偏好的多个对话步骤，以及（ii）系统呈现结果、提供解释或显示不同替代方案之间比较的特殊对话状态组成。可能的转换在设计时定义，但在对话期间采取哪条路径是基于决策规则动态确定的。另一个基于预定义状态集和可能转换的工作示例是[86]中提出的交互式旅游推荐系统。在他们的案例中，运行时的转换不是基于手工设计的决策规则确定的，而是使用强化学习技术从数据中学习，其中一个目标是最小化所需的交互步骤数量。

从技术上讲，有多种方法可以显式表示此类状态机。一些工具，如上文提到的，使用视觉表示，而其他工具则依赖文本和声明性表示，如“对话语法”[13]和案例框架[12]。以Google的DialogFlow4为例，作为一种商业服务，它使用视觉工具来建模线性和非线性对话流程，其中非线性意味着存在不同的执行路径，取决于用户的响应或上下文因素。最后，在某些情况下，可能的状态只是硬编码为应用程序的通用程序逻辑的一部分。

在一些工作中，特别是在早期基于表单和按钮的批评方法中[122, 123, 134]，只存在一些通用的对话状态，这意味着不需要设计复杂的流程。在初始偏好获取阶段之后，推荐被呈现，系统提供一些用户可以应用的批评，直到推荐被接受或拒绝。因此，对话状态管理在某些方面相对轻量。系统在对话管理方面的主要任务是跟踪用户响应，并在动态批评的情况下，推断出要提供的下一个批评。

同样，在一些基于自然语言处理（NLP）的对话式偏好获取系统中，如[29, 172]，主要有两个阶段：以自适应方式提问和呈现推荐列表。在其他基于NLP的系统中，可能的对话状态并没有明确建模，而是从实现的意图中隐式地产生。例如，是否存在“提供解释”的对话状态取决于在系统设计阶段是否考虑了相应的意图。

最后，在[75]中提出的基于NLP的端到端学习CRS中，对话状态在某种程度上也是隐式建模的，但方式不同。该系统基于以电影推荐为中心的人类对话（在众包工作者之间）的语料库。该语料库用于训练复杂的神经模型，然后用于对用户的发言做出反应。从对话示例来看，这些对话除了闲聊外，主要是一个通信伙伴询问另一个是否喜欢某部电影。然后分析电影寻求者回答的情绪以做出另一个推荐，再次以问题的形式。因此，对话模型相对简单，并编码在神经模型中。它似乎不支持许多其他类型的意图或不包含电影名称的信息请求（例如，“我想看一部科幻电影”）。

4.4 Background Knowledge

除了讨论的关于支持的用户意图集或可能的对话状态的知识外，对话式推荐系统（CRS）还基于其他类型的知识和数据。例如，这些知识包括与项目相关的信息（例如属性和评分）、用于学习的记录的自然语言对话语料库，以及用于实体识别的额外知识源。

4.4.1 Item-related Information.

与任何推荐系统一样，对话式系统也必须访问包含可推荐项目信息的数据库。这样的数据库可以包含项目评分、可以呈现给用户的元数据（例如电影的类型或导演）、社区提供的标签或提取的关键词。这些项目属性还可以作为其他计算任务的基础，例如计算个性化推荐、生成解释或确定可以向用户提出的问题。

在审查的论文中，我们发现研究人员使用了多种不同的数据库。一些工作基于典型的评分数据集，例如来自MovieLens或Netflix的数据集，而其他研究人员创建了自己的数据集或依赖于来自不同领域的现有数据集。在表2中，我们提供了包含项目相关信息的数据集示例。可以观察到，例如在基于批评的应用程序中，研究人员仅依赖他们为研究目的创建或收集的数据集，即其他研究人员对数据集的重用有限。一个主要的原因是，在我们分析的大多数论文中，研究人员没有公开分享他们的数据集。

4.4.2 Dialogue Corpora Created to Build CRS.

基于自然语言处理（NLP）的对话系统通常基于由记录且通常经过注释的人类对话（交互历史）组成的训练数据。因此，许多倡议致力于创建可用于构建对话式推荐系统（CRS）的数据集。相比之下，其他研究人员依赖于为其他目的创建或收集的对话数据集。通常，这些语料库可以通过众包工作者[64, 75, 139]、注释访谈[16, 18, 109]或记录与聊天机器人的交互[63]来获得。表3显示了最近研究中使用的此类数据集的示例。

请注意，在构建对话式推荐系统（CRS）时，这些对话语料库有时会与其他知识库结合使用[75, 170]。例如，在[75]中，对话语料库和MovieLens数据都用于情感分析和评分预测的目的。当对话中没有足够的相关信息时，这种数据集的组合可能是必要的。

4.4.3 Logged Interaction Histories.

构建一个有效的对话式推荐系统（CRS）需要理解用户的对话需求，例如他们更喜欢如何提供偏好，他们可能有哪些意图等。更好地理解这些需求的一种方法是记录和分析用户与原型系统之间的交互。这些日志随后作为进一步研究的基础。与上述讨论的对话语料库不同，这些数据集通常并非主要用于构建CRS，而是为了更好地理解用户的交互行为。例如，在[154, 155]中，分析了用户与特定基于NLP的CRS的交互，以评估对话质量和对话策略。在[16, 18]中，在开发推荐系统之前进行了用户研究，以理解和分类用户可能的反馈类型。在一些方法中，如[18, 114]，研究人员为此类数据集进行注释和标记，以用于模型训练和系统初始化。然而，除了[114]之外，这些记录的历史通常比上述讨论的对话语料库小得多，主要是因为它们是在有限参与者数量的研究中收集的。通过记录系统交互和用户研究获得的数据集示例如表4所示。

4.4.4 Lexicons and World Knowledge.

研究人员经常使用额外的知识库来支持基于自然语言处理（NLP）系统中的实体识别过程。例如，在[73, 80]中，从维基百科或Wikitravel等在线资源中提取信息，以开发用于实体-关键词映射的词典。同样，在[73]中使用了WordNet语料库来确定对话中识别出的关键词与预定义实体之间的语义距离。更多关于词典和世界知识使用的示例如表5所示。

4.5 Discussion

我们的讨论表明，对话式推荐系统（CRS）可以是知识密集型或数据密集型系统。与传统推荐问题公式化不同，在传统推荐问题中，目标是对未见项目进行相关性预测，CRS通常需要比用户-项目评分矩阵更多的背景信息，特别是在对话管理方面。

Pre-defined Knowledge vs. Learning Approaches.

在使用表单和按钮作为唯一交互机制的CRS方法中，交互流程通常以可能的对话状态、支持的用户意图集和要获取的用户档案属性的形式预定义。相比之下，基于自然语言处理（NLP）的系统在对话流程方面通常更加动态，它们依赖于额外的知识源，如对话语料库和答案模板，以及词典和词汇知识库。然而，这些系统通常需要手动定义额外的背景知识，例如关于支持的用户意图。

纯粹从记录的对话中进行的“端到端”学习似乎具有挑战性。在大多数现有方法中，支持的交互模式集是隐式或显式预定义的，例如以“用户提供偏好，系统推荐”的形式。在某种程度上，人类对话的收集也可以设计为支持可能的系统响应，如[75]中所示，其中众包工作者被给予关于预期对话的具体指示。因此，支持的对话话语范围可能相对狭窄。例如，[75]中提出的系统无法处理“请推荐一部好的科幻电影”这样的查询。

Intent Engineering and Dialogue States.

在需要更丰富的对话和额外功能的情况下，支持的用户意图的定义通常是CRS开发过程中的核心且通常是手动的任务。然而，与通用对话系统和家庭助手相比，支持的用户意图集通常相对较小。我们在第4.1节中确定了一些常见的意图类别。根据领域的不同，也可以支持非常特定的意图，例如在时尚推荐系统中询问风格提示[105]。此外，在专为群体决策场景设计的CRS中，还需要支持另一组可能的用户意图。典型的用户意图可以涉及邀请协作者[103]或请求群体推荐。此外，可能存在与解决偏好冲突和群体成员投票相关的用户话语[1, 91, 103]。

通常，系统支持的用户意图集决定了最终对话的丰富性和多样性。无法适当地回应用户话语可能严重损害系统的质量感知。例如，能够解释系统做出的推荐通常被认为是使决策更容易或增加用户对推荐系统信任的关键特征。因此，如果系统无法识别和回应解释请求，基于NLP的系统的用户可能会对对话感到失望。

因此，一个关键挑战是预测或随着时间的推移学习用户可能有哪些意图。根据应用和使用的技术，意图数据库的设计和实现（例如使用Google的DialogFlow引擎）可能导致大量的手动工作，并需要专业作家的参与，以实现对话的某种自然性和丰富性。同时，主要解决方案提供商实施的基于规则的建模方法（“如果这样，那么那样”）可能容易导致难以维护的大型知识库，从而需要替代的建模方法[140]。

5 COMPUTATIONAL TASKS

在讨论了推荐对话中可能的用户意图之后，我们现在将回顾对话式推荐系统（CRS）的常见计算任务和技术方法。我们区分（i）主要任务，即与推荐过程更直接相关的任务，例如计算推荐或确定下一个要问的问题，以及（ii）额外的支持任务。

5.1 Main Tasks

广义上讲，CRS在对话期间执行四种一般类型的任务（或：系统动作）：请求、推荐、解释和响应，参见图4。然而，并非每个CRS都必然实现所有这些任务。系统驱动的CRS（如第3.3节所述）通常通过请求用户对属性的偏好并允许用户通过多个交互周期对推荐进行反馈来推动对话。相比之下，用户驱动的系统可以扮演更被动的角色，主要响应用户的对话行为。在混合倡议系统中，例如基于自然语言界面的系统，可以找到所有类型的动作。

5.1.1 Request.

许多CRS遵循“槽填充”对话方法，系统试图获取关于预定义项目属性或方面的偏好信息。在此上下文中的一个主要计算任务是确定下一个要问的问题，通常目的是提高对话效率，即最小化所需的交互次数（另见第6节）。文献中提出了各种确定方面顺序的方法[20, 132, 142, 170]。在早期系统[142]中，使用特定权重对用户尚未表达偏好的项目属性进行排名。基于熵的方法还考虑了每个属性对剩余项目空间的潜在影响。它们旨在识别下一个问题（属性），这有助于最大程度地缩小候选（项目）空间[20, 96, 104, 132, 166]，有时包括特征流行度信息[96]。这样的考虑通常也是典型动态和复合批评系统的基础[25, 90, 111, 121, 134, 148, 171]。特别是在复合批评系统中，用户不是被要求对一个单一属性提供反馈，而是在一次交互中对多个属性提供反馈，例如“不同的制造商，更低的处理器速度和更便宜”。最后，在一些系统中，向用户提出的可能问题序列以状态机的形式预定义[55, 58]。在运行时，然后根据用户在会话中的输入选择对话路径。

与其使用启发式方法进行属性选择和静态对话状态转换规则，许多更近期的系统依赖于基于学习的方法，例如使用强化学习[86, 139, 146]。在[139]中，例如，作者使用深度策略网络来决定系统动作。基于由信念跟踪器建模的当前对话状态，系统要么请求预定义的方面，要么生成推荐显示给用户。在[30]中提出了一种替代的基于学习的方法来确定问题顺序。在他们的工作中，作者设计了一个YouTube推荐器，利用用户社区的过去观看历史和循环神经网络架构来排名在对话步骤中向用户展示的问题（主题）。

询问用户基于属性的偏好的替代方法是要求他们对选定的项目进行反馈。这可以通过要求他们对单个项目进行评分（例如通过喜欢/不喜欢声明）或要求他们表达对项目对或整个项目集的偏好来实现[81]。在此上下文中的计算任务是确定向用户展示的最具信息量的项目。可能的策略包括在冷启动阶段选择受欢迎或多样化的项目，过去评分或属性不同的项目，或代表受欢迎度和多样性平衡的项目集[17, 93, 101, 120]。然而，不仅项目特征可能与项目选择相关。在[17]中，作者发现用户对项目提供反馈的意愿可能取决于额外因素。具体来说，他们确定了反馈概率可能更高的几种情况，例如当系统的预测评分与用户过去的项目经验偏差时。在更近期的作品中，基于学习的方法再次更为常见。例如，[29, 174]的作者采用基于bandit的方法来（i）确定下一个要展示的项目以获取用户的绝对反馈（即喜欢或不喜欢），或（ii）选择一对项目以获取用户对这两个项目的相对偏好。

5.1.2 Recommend.

项目推荐是任何对话式推荐系统（CRS）的核心任务。从技术角度来看，我们可以在文献中找到协同过滤、基于内容、基于知识和混合方法。与非对话系统不同，大多数分析的CRS方法主要仅依赖于短期偏好信息。然而，也有一些方法额外考虑用户的长期偏好，例如，以加快获取过程[82, 103, 125, 130, 139, 142, 154]。

在基于批评和基于知识的系统中，应用了不同的策略来过滤和排名项目。对于过滤任务，通常应用基于约束的技术[42]，从候选集中删除与当前用户偏好不完全匹配的项目。然后可以以不同方式对剩余项目进行排序[169]。例如，在[171]中提出的系统中，用户偏好模型在用户批评后通过调整批评中涉及的属性权重进行更新。然后，使用多属性效用理论（MAUT）[67]计算每个候选项目的效用，以生成用户的top-K推荐。在[130]中应用了另一种排名方法，其中提出了一个历史引导的批评系统，旨在从与当前用户相似的其他用户的批评会话中检索推荐候选者。在[39]中，实现了一个基于批评的旅行推荐系统，该系统基于项目属性与用户偏好的相关性计算推荐，基于欧几里得距离。

一些作品在做出推荐时同时考虑了用户的长期和短期偏好[4, 82, 123, 130]。自适应地点顾问系统[142]是结合短期和长期偏好的早期示例。在这里，用户的当前查询通过考虑用户过去对项目属性偏好的概率分布进行扩展，基于她/他的短期约束（在一次对话中）和长期约束（在多次对话中）。然后使用此扩展查询检索和排名项目以进行推荐。在[130]中，作者提出利用先前对话中的成功推荐会话来提高当前会话的效率（即缩短其长度）。

更近期的作品依赖于机器学习模型和背景数据集进行推荐任务。一种常见的方法是在传统的用户-项目交互矩阵上训练模型，例如基于概率矩阵分解[29]，然后将用户的当前交互与训练的用户和项目嵌入结合。在另一种方法[4]中，作者在冷启动阶段依赖于基于项目特征和用户档案的基于内容的方法，然后一旦获得足够数量的偏好信号，就切换到受限玻尔兹曼机协同过滤方法。在[172]中，训练了一个带有注意力机制的混合多记忆网络，以基于项目嵌入和用户查询嵌入找到合适的推荐。在这里，项目嵌入基于项目的文本描述，用户查询嵌入编码了用户的初始请求和交互期间的后续对话。在[139]中也提出了一个混合模型，该模型使用因子分解机结合对话状态——用基于LSTM的信念跟踪器表示每个项目方面——用户信息和项目信息来训练推荐模型。在[30]中提出的视频推荐系统中，最终，基于用户选择的主题和他们的观看历史，构建了一个基于RNN的模型来进行推荐。

在某些情况下，应用了特定于应用的技术进行推荐任务。例如，在[167, 168]中，CRS具有一个视觉对话组件，用户可以根据图像提供反馈，例如“我更喜欢蓝色”。为了实现这一功能，[167]中提出的系统实现了一个组件，使用卷积神经网络编码项目图像和用户反馈，然后将这些编码作为响应编码器和状态跟踪器的输入。此外，在bandit方法中考虑了在视觉表示推荐上的各种用户行为（即查看、评论、点击），以平衡探索和利用。

5.1.3 Explain.

在一般推荐系统中，解释的价值被广泛认可[51, 106, 143]。解释可以增加系统的透明度、用户信任和满意度，并且可以帮助用户做出更快更好的决策[45]。然而，根据我们的调查，迄今为止很少有论文研究特定于CRS的解释问题。

在基于批评的系统中，[110]研究了解释的信任建立性质。在这项工作中，评估了一种“基于组织”的解释方法，其中系统向用户显示多个推荐列表，每个列表都基于批评选择标准进行标记，例如“更便宜但更重”。在[69]中提出了一种更近期的基于移动批评推荐器的交互式解释方法，其中向用户显示的文本解释基于用户的偏好，并从预定义的模板构建。

提供关于推荐项目的更多信息，例如以优缺点形式，是提供解释时的典型方法。在CRS背景下以用户定制的方式生成此类项目描述在[43]和[150]中提出。在此类方法中，对话期间用户的反馈可以影响在推荐阶段向用户显示的项目描述中提到的属性。此外，可以考虑用户偏好来排序参数，并帮助确定在解释中使用哪些形容词和副词[43]。

在[101]中，在电影CRS中实现了两种解释。一种简单地基于给定电影的详细信息，而另一种通过基于图的方法将给定用户偏好与项目特征连接起来，以创建个性化解释。在[97]中提出了另一种基于图的方法，讨论了用于开放式对话的知识增强对话系统。在这种方法中，通过遍历一个常见事实知识图检索对话上下文中的相关实体和属性，并使用遍历路径为给定推荐创建解释。在[109]中，最终采用了一种以人为本的方法。通过分析人类对话数据集，作者确定了不同的社交策略来解释电影推荐。然后，他们在对话推荐系统中适应了社交解释，以提高用户对系统质量的感知。

然而，对于解释的主要任务，我们发现迄今为止存在的CRS特定研究很少，并且文献中提出的CRS中只有一小部分支持这种功能。

5.1.4 Respond.

这类任务在用户驱动或混合倡议的基于自然语言处理（NLP）的CRS中相关，用户可以主动向系统提问、主动做出偏好声明或发出命令。系统的目标是正确回应用户话语，这些话语不属于上述“推荐”和“解释”类别。可以采用两种主要类型的技术方法来响应此类用户话语。一种方法——也常用于聊天机器人——是将话语映射到预定义的意图，例如表1中提到的那些，例如获取详细信息或重新启动。系统对这些预定义意图的答案可以在系统的帮助下用模板实现。在文献中，提到了各种用户话语，CRS应能够适当地响应。示例包括偏好细化，例如“我喜欢《低俗小说》，但不喜欢昆汀·塔伦蒂诺”[101]，请求关于项目的更多信息，或请求系统对某个项目的判断，例如“华为P9怎么样？”[164]。

另一种技术方法是通过从对话语料库和其他知识源自动训练机器学习模型来选择或生成系统的响应，例如在“端到端”学习系统中，例如[27, 63, 64, 75]。例如，在[114]中描述的开放域对话系统中，使用信息检索模型从问答知识库（在线客户服务聊天日志）中检索初始候选答案集。然后，使用注意力序列到序列模型对候选答案进行排名，以确定得分高于预定义阈值的答案。如果没有现有答案被认为合适，则使用基于序列到序列的模型生成系统的响应。

在[105]中描述了这种方法的另一个示例。在这个多模态推荐系统中，使用一个RNN模型生成一般响应，如问候或闲聊，并训练一个知识感知的RNN模型来回答更具体的问题。例如，当用户询问风格提示：“T恤会与这些凉鞋搭配吗？”，系统可能会回答“是的，T恤会与这些凉鞋搭配得很好”[105]。

最后，文献中提出了一些方法来处理非常特定的对话情况。这种情况的一个示例是对话中断，系统无法理解用户的输入[98]。在人机交互领域研究了可能的修复策略，如礼貌和道歉策略，以减轻此类中断的负面影响[71, 74, 136]。基于通信理论的各种修复策略，例如重复或请求澄清，或来自可解释机器学习的策略，例如解释对话的哪些部分未被理解，原则上可以应用[6]。

5.2 Supporting Tasks

根据系统的功能，对话式推荐系统（CRS）中可能涉及许多额外的支持性计算任务。

Natural Language Understanding.

在基于自然语言处理（NLP）的CRS中，系统理解用户话语背后的意图至关重要，因为这是选择适当系统动作的基础[118]。在此上下文中的两个主要任务是意图检测和命名实体识别，典型的CRS架构有相应的组件来处理此任务。原则上，意图检测可以被视为分类任务（对话行为分类），其中用户话语被分配到一个或多个意图类别[137]。命名实体识别旨在将给定话语中的实体识别为预定义的类别，如产品名称、产品属性和属性值[164]。

尽管意图检测和命名实体识别在一般对话系统中得到了广泛研究[137]，但根据我们的调查，特定于CRS的研究很少，可能是因为缺乏完善的分类法和大规模注释的推荐对话数据。在早期方法[142]中，使用手动定义的识别语法将用户话语映射到预定义的对话情况，这与在上述响应任务上下文中使用预定义意图相当。在[164]中可以找到更近期方法的示例。在这里，在一个在线购物对话系统中实现了一个自然语言理解组件，用于意图检测、产品类别检测和产品属性提取。例如，从话语“推荐我一部5.2英寸屏幕的华为手机”中，系统应推导出意图推荐、产品类别手机，以及品牌和显示尺寸。为了解决这些任务，作者首先从社区网站上发布的查询中收集了与产品相关的问题，然后使用两种基于短语的算法提取意图短语（例如，“想买”和“怎么样”）。训练了一个多类分类器用于新用户问题的意图检测。至于产品类别检测，作者采用了一种基于CNN的方法，该方法考虑检测到的意图来识别给定话语中提到的产品类别。

神经网络也在其他最近的意图和实体识别方法中使用[105, 146]。例如，在[105]中使用了一个多层感知器（MLP）来预测一组预定义意图类别上的概率分布。在[166]中使用了一个序列到序列模型来将用户的查询（例如，“如何保护我的iPhone屏幕”）重新表述为关键词（例如，“iPhone屏幕保护器”），然后在推荐过程中使用这些关键词来识别候选项目。

在一些应用中的另一个支持任务是情感分析，参见例如[54, 75, 100, 105, 173]。在CRS上下文中的一个典型目标是理解用户对某个项目的看法。例如，每当在话语中提到一个项目——例如一部电影——时，句子的情感可以用来近似用户对该项目的感觉。然后可以将此情感视为项目评分，随后可以使用已建立的推荐技术推荐其他项目。

Specific Recommendation Functionality.

根据生成推荐的技术方法，可能需要特定的计算子任务来支持推荐过程。我们将在此处从基于批评的方法上下文中给出示例。例如，在[11, 145]中，目标是向用户提出“查询建议”，其中术语“查询”等同于对项目特征的批评或约束。在上述方法中，查询建议（或修改）基于对查询可满足性的扩展分析（即建议的查询是否会导致任何结果）或可能查询建议之间的支配关系。通常，这样的查询建议对于难以表达其偏好的用户特别有帮助。在信息检索领域，提出了许多查询建议方法，以帮助用户表达其信息需求，例如，参见[135]中的更近期示例。然而，迄今为止，将此类想法应用于CRS上下文的工作有限。

在基于约束的CRS中，一个相关的问题是，在某些情况下，用户表达的偏好导致要么剩余太多项目进行推荐，要么没有项目剩余。文献中提出了不同的查询松弛方法。例如，在[142]中，采用了一种相对简单的策略来移除一些约束。在[56, 94]和[124]中提出了更精细的策略。在后一项工作[124]中，作者还引入了“查询紧缩”的概念。这里的想法是在系统返回的相关项目数量会导致选择过载问题的情况下，对项目属性添加更多约束。通常，与上述查询建议方法类似，类似的查询修订方法（松弛和紧缩）在基于NLP的CRS上下文中并未得到广泛探索。一个例外是在[104]中提出的聊天机器人概念，其中系统首先尝试识别不成功查询的原因，然后要求用户移除一些偏好并按重要性对项目特征进行排序。最后，不是返回空结果并要求用户修订偏好，而是存在自动松弛约束并通知用户的方法，例如“有10台相机价格低于300欧元，但它们的分辨率在1到4百万像素之间”[55, 90]。

5.3 Discussion

我们的另一个观察是，对话管理通常被勾勒为一个概念性架构组件，但随后要么以相当静态的方式实现，带有预定义的转换，例如参见[86, 172]，要么在意图识别和映射阶段隐式完成，或由偏好获取策略的选择确定，例如槽填充[162]。在某些情况下，可能的对话状态相当有限，例如系统可以决定提问或提供推荐[139]。技术上，在少数情况下，意图识别和对话流程管理基于商业工具，例如参见[5, 36]。

一般来说，随着聊天机器人应用的广泛传播，一些商业公司如Google、Microsoft、Facebook和IBM已经发布了框架或公共API，实现了一些上述计算任务，并允许开发者创建自己的聊天机器人。这些工具包括Google的DialogFlow系统、Facebook的Wit.ai和IBM Watson Assistant 5，并提供诸如语音识别、语音控制、从自然语言话语中识别预定义意图、对话流程管理、对特定意图的响应生成以及将应用程序部署到商业平台等功能。使用这些服务的研究工作示例包括[3, 5, 21, 36, 62, 65, 133]。Microsoft通过其Bot Framework和Amazon为其Alexa助手和智能音箱也提供了开发对话系统的框架。例如，在[4]中提出了一个使用Amazon Echo智能音箱的旅行领域CRS。然而，一般来说，这些框架和服务通常不实现特定于推荐问题的功能，而是设计用于构建通用对话系统。

除了公司，一些研究人员也向公众发布他们基于NLP的CRS。示例包括VoteGoat电影推荐器[36]和用于聊天机器人开发的ConveRSE框架[54, 101]。

6 EVALUATION OF CONVERSATIONAL RECOMMENDERS

一般而言，推荐系统可以通过多种维度进行评估，采用不同的方法论途径[131]。首先，当系统在其使用环境中进行评估时，即系统部署后，我们通常主要关注特定的关键绩效指标（KPIs），这些指标通过A/B测试来衡量系统是否达到了设计目标，例如增加的销售额或用户参与度[57]。其次，用户研究（实验室实验）通常探讨与系统感知质量相关的问题。常见的质量维度包括推荐的适宜性、过程的感知透明度或易用性，参见[113]。最后，离线实验不涉及用户在评估中的参与，而是基于客观指标来评估质量，例如通过测量推荐多样性或计算运行时间来预测测试集中保留评分的准确性。

同样的一套质量维度和研究方法也适用于对话推荐系统（CRS）。然而，在比较以算法为导向的研究与对话系统的研究时，我们发现评估的主要焦点往往有所不同。由于CRS是高度交互的系统，因此这些系统更常研究与人类-计算机交互方面相关的问题。此外，在测量方法方面，CRS的评估不仅关注任务完成情况，即推荐是否合适或最终被接受，还关注与对话本身的效率或质量相关的问题。

6.1 Overview of Quality Dimensions, Measurements, and Methods

通过我们的文献综述，我们识别出在对话推荐系统（CRS）研究中探讨的以下主要质量维度类别：

(1) 任务支持的有效性：这一类别指对话推荐系统（CRS）支持其主要任务的能力，例如帮助用户做出决策或找到感兴趣的项目。
(2) 任务支持的效率：在许多情况下，研究人员还关注用户找到感兴趣的项目或做出决策的速度。
(3) 对话质量与可用性方面：这一类别的研究分析集中于对话本身的质量以及CRS整体的可用性（易用性）。
(4) 子任务的有效性：在我们的调查中，许多研究关注某些子任务，如意图识别或实体识别。

在每一个维度中，文献中都考虑了多种不同的测量方法。例如，任务有效性可以通过客观指标（如准确率、接受率或拒绝率）或主观指标（如与选择满意度或感知推荐质量相关的调查）来衡量。任务效率通常通过所需的交互步骤数量来客观衡量，较短的对话通常被认为更优。对话质量则最常通过主观评估来分析，例如流畅性、可理解性或回答质量。最后，针对子任务的特定测量包括意图识别率或状态识别过程的准确性。

从方法论的角度来看，我们发现一些研究完全依赖于离线实验，一些研究仅依赖于用户研究，还有一些研究将离线实验与用户研究相结合。关于实际部署系统和A/B测试的报告较为罕见。讨论已部署系统的例子包括[20, 30, 32, 55, 60, 104, 114, 164]。然而，这些测试提供的细节水平通常有限，部分是非正式的，或者仅考虑某些方面（如处理时间）。最后，我们还发现了一些没有任何评估的研究，或者评估主要是定性或基于轶事的研究[4, 73, 160]。

在实验评估中，使用了各种材料——特别是原型应用程序——和数据集。正如第4节所讨论的，至少需要一个项目数据库。根据技术方法的不同，还会使用其他类型的知识和数据，例如人类之间的对话日志、显式的对话相关知识（如支持的意图等）。

在图5中，我们概述了最常见的评估维度和评估方法，并提供了典型测量和数据集的示例。在接下来的章节中，我们将更详细地讨论一些更典型的评估方法。

6.2 Review of Evaluation Approaches

6.2.1 Effectiveness ofTask Support.

在传统推荐系统中，最常见的评估方法是通过离线实验来确定算法在预测某些已知但被隐藏的用户偏好时的准确性。其基本假设是，具有更高准确性的系统更有效，例如在帮助用户找到所需内容方面。客观的准确性指标，如均方根误差（RMSE）或命中率（Hit Rate），有时也用于评估对话推荐系统（CRS）。然而，对话系统通常没有长期可用的用户偏好，系统只能在当前使用会话中了解用户偏好。因此，通常采用依赖于模拟用户或用户研究的替代评估协议。此外，研究人员有时会使用除准确性之外的特定客观指标，并且也经常依赖用户的主观质量评估[27, 75, 139]。下面将详细讨论这些客观和主观的质量测量方法。

Objective Measures.

例如，在[18, 29, 101]或[146]的评估中，使用了诸如平均精度（Average Precision）、命中率（Hit Rate）或均方根误差（RMSE）等准确性指标。在[29]中，提出了一种用于交互式偏好获取的框架，该框架学习在冷启动阶段应向用户提出哪些问题。为了评估不同策略，作者使用了真实和模拟的用户配置文件，并报告了每一轮问答后推荐的平均精度。类似地，在[146]和[139]中，使用用户模拟器评估了基于深度强化学习和端到端记忆网络的对话式面填充推荐系统。[146]中的模拟器基于从餐厅预订数据集[63]中提取的真实用户话语。客观指标包括推荐准确性（排名中位数和成功率），以及接受推荐的模拟用户比例。在[139]中，“在线”实验基于通过众包工作者收集的数据集，客观指标包括强化学习策略的平均奖励和成功率（转化率），即成功对话的比例。

[101]的作者提出了一种领域无关的CRS框架，并使用命中率（Hit Rate）来评估不同系统组件（如推荐算法或意图识别器）的有效性。为了进行测量，他们使用了上述的bAbI数据集作为基准真值，其中每个示例包含用户偏好、推荐请求和推荐项目。[27, 64, 75]中采用了类似的评估方法，基于从不同真实世界对话中提取的基准真值信息和准确性指标（RMSE、召回率、命中率）。在这种方法中，系统通常分析正在进行的自然语言对话中对项目（如电影）的（积极）提及，并将这些偏好用于预测任务。

[18]的重点是CRS中的隐式反馈，这种反馈是通过非语言交流行为获得的。为了评估使用这些信号的有效性，使用MAE和RMSE评估了基于内容的推荐器的评分预测准确性。在他们的方法中，评估的基准真值是在用户研究中预先收集的。在某种程度上，这种方法与[101]类似，因为都研究了子任务性能（在这里是非语言交流行为的解释）对系统整体推荐质量的影响。

鉴于纯离线实验在CRS背景下的可能局限性，用户研究也经常被用来衡量系统的有效性。例如，在基于批判的系统[23, 24]中，决策准确性通过用户在CRS的帮助下做出选择后，当呈现所有可用选项时改变主意的用户比例来客观衡量。相比之下，在[86]中，作者使用任务完成率和加入购物车动作作为代理指标，分别衡量用户至少有一个商品在购物车中的频率以及他们平均添加了多少商品。

Subjective Measures.

与客观指标（例如记录用户与系统交互时的决策行为或通过模拟确定预测准确性）不同，主观指标评估用户对系统的质量感知。这样的测量可能很重要，因为即使是常见的准确性指标也往往无法预测用户感知的推荐质量。6 在回顾的CRS文献中，研究了各种质量因素，这些因素也常用于非对话推荐系统，例如[68]和[113]中讨论的评估框架中的因素。因此，对于[23, 24]中讨论的基于批判的系统，作者不仅使用了决策准确性（作为客观指标），还评估了不同因素，如决策信心、购买意图和退货意图。用户满意度，无论是针对系统的推荐还是系统整体，在早期的批判方法（如[112, 125]）和其他比较评估（如[101, 165]）中也进行了研究。在[47]的语音控制批判系统中，评估了感知的推荐质量，而在[152]中，作者关注了用户接受率。最后，在[62, 81]和[109]中，作者在问卷中考虑了多个维度，如推荐与偏好的匹配度（兴趣契合度）、推荐会被喜欢的信心以及信任。

与客观指标（例如记录用户与系统交互时的决策行为或通过模拟确定预测准确性）不同，主观指标评估用户对系统的质量感知。这样的测量可能很重要，因为即使是常见的准确性指标也往往无法预测用户感知的推荐质量。6 在回顾的CRS文献中，研究了各种质量因素，这些因素也常用于非对话推荐系统，例如[68]和[113]中讨论的评估框架中的因素。

因此，对于[23, 24]中讨论的基于批判的系统，作者不仅使用了决策准确性（作为客观指标），还评估了不同因素，如决策信心、购买意图和退货意图。用户满意度，无论是针对系统的推荐还是系统整体，在早期的批判方法（如[112, 125]）和其他比较评估（如[101, 165]）中也进行了研究。在[47]的语音控制批判系统中，评估了感知的推荐质量，而在[152]中，作者关注了用户接受率。最后，在[62, 81]和[109]中，作者在问卷中考虑了多个维度，如推荐与偏好的匹配度（兴趣契合度）、推荐会被喜欢的信心以及信任。

6.2.2 Efficiency ofTask Support.

传统上，特别是基于批判的CRS方法，通常从推荐过程的效率角度进行评估。具体而言，生成动态批判的目标之一是尽量减少用户找到所需项目或接受推荐所需的交互次数。此类评估通常使用模拟用户配置文件离线进行。一个假设是，即使在非基于批判的方法中，模拟用户也会理性且一致地行动，即他们不会在过程中修改自己的偏好。

测量批判方法中交互周期的研究包括[47, 86, 89, 91, 122, 125, 147, 171]。所需的交互阶段数量也是通常用于类聊天机器人应用程序（如[53, 62, 101, 154]）和[152]中的购物决策辅助工具的多个评估标准之一。在学习型系统的背景下，[139]中测量了两阶段交互模型中的对话轮次数量。

然而，这种测量在基于自然语言的学习型对话系统中并不常见。除了交互阶段数量外，任务完成时间有时被用作客观测量效率的替代或补充方式，例如在[62, 86]中。在[54]中，作者比较了不同交互模式（基于自然语言处理、基于按钮和混合模式）与聊天机器人的效率，测量了对话中的问题数量、交互时间和每个问题的时间。他们的主要发现是，纯自然语言界面导致推荐会话效率较低，部分原因是正确解释自然语言话语的问题。

在上述论文中，较短的交互或任务完成时间通常被认为是有利的。然而，需要注意的是，在某些情况下，较长的会话是可取的。特别是，较长的交互时间可能反映了更高的用户参与度，例如在[62]中，这与音乐应用程序中听歌数量的增加相对应。在[28]中，作者比较了基于语音和视觉输出的系统，并测量了用户探索的选项数量。在这种情况下，探索更多项目可能既表明用户找到了更多有趣的选项，也可能表明用户没有立即找到某物，不得不探索更多选项。在[165]中，分析了使用语音界面进行播客推荐的效果。他们的结果显示，用户速度较慢，探索的选项较少，选择的长尾项目也较少，这可能不利于发现。

最后，在一些研究中，使用了对过程效率的主观测量，通常作为可用性评估的一部分。在[23, 81, 109, 152]和[86]中，作者询问研究参与者感知的认知努力。

6.2.3 Quality ofthe Conversation and Usability Aspects.

在许多研究中，评估的重点放在对话质量的某些方面以及系统整体的可用性方面。例如，在[47, 62, 112, 122]中研究了系统的一般易用性；更具体的概念“任务易用性”是[154]中用户问卷的一部分。

关于对话本身的质量方面，文献中研究了各种因素。从对话主动性的角度来看，[81]和[109]的作者测量了用户感知的控制水平。[62]研究了控制欲是否取决于个人特征。除了用户控制外，[109]中将感知透明度视为一个质量因素。建立透明度的常见方法是通过使用解释。[108]研究了如何为推荐聊天机器人设计解释的问题。[154]中使用的质量因素基于[78]中早期评估语音对话系统的框架。例如，包括适应性（即系统如何快速适应用户偏好）、预期行为（即对话交互的直观性和自然性）或娱乐价值。此外，[109]中将协调、相互关注、积极性和融洽关系视为对话的额外期望因素。

更详细地观察对话的内容和语言层面，许多基于自然语言的最新提案依赖BLEU [107]评分来评估系统的响应，例如[64, 75–77, 105]。借助这一在机器翻译背景下开发的评分，可以自动比较系统生成的响应与真实人类对话的基准响应。作为替代，可以使用NIST评分，例如在[105]中。文献中测量的其他客观语言方面包括词汇多样性[46]、困惑度（对应于流畅性）和独特的n-gram（用于评估多样性）[27]。除了这些客观语言测量外，研究人员有时在评估中考虑对系统响应的主观评估，例如关于流畅性、适当性、一致性、吸引力、相关性、信息量以及整体对话质量和生成性能[27, 46, 64, 76, 77, 105, 154]。

6.2.4 Effectiveness ofSub Task.

最后，在一些研究中，研究人员专注于评估某些子任务的性能。同样，这些测量可以是客观的或主观的。作为客观测量，在依赖强化学习的方法中通常计算奖励[86]。在批判系统中，[122]中研究了提出的批判被应用的次数。相比之下，在基于自然语言处理的系统中，研究人员经常评估实体和意图识别模块的性能[77, 101]。在[105]中的特定多模态CRS中，使用召回率评估图像选择性能。在主观测量方面，例如在[154]中考虑了解释性能，即系统在理解输入方面的表现。

6.3 Discussion

我们的综述表明，用于评估对话推荐系统（CRS）的方法和指标多种多样。原则上，[68]和[113]中提出的以用户为中心的推荐系统评估框架也可以应用于CRS。然而，迄今为止，尽管以用户为中心的评估很常见，但这些框架并未被广泛使用，文献中也没有提出相关的标准或扩展。在客观测量方面，一些研究人员使用了典型的准确性指标。尽管如此，文献中的个别CRS提案在应用领域、交互策略和背景知识等方面存在很大差异，现有系统之间的比较仍然具有挑战性。

在基于自然语言处理的系统中，BLEU评分被广泛用于自动评估。然而，根据[79]，BLEU评分（至少在句子层面）可能与用户感知的相关性较差，参见[46]。一般来说，语言模型的评估通常被认为具有挑战性[88]，而像CRS这样的任务导向系统可能更加难以评估。因此，这些观察表明，仅凭BLEU评分无法很好地反映生成系统话语的质量，还应结合主观评估。

因此，研究人员通常依赖于离线实验（使用模拟用户）或用户研究，其中研究参与者需要完成特定任务。在离线研究中，通常随机选择一个目标（首选）项目，然后模拟一个理性行为的用户，通过与CRS交互（例如回答偏好问题或提供对解释的反馈）来完成评估。然而，这种设计假设用户对项目或项目特征有先验的固定偏好。实际上，用户在对话中了解选项空间时可能会构建或改变他们的偏好。因此，这种模拟在多大程度上反映真实世界的情况并不完全清楚。相比之下，用户研究通常探索现实的决策情境，参与者需要完成诸如在商店中选择产品或为生日派对找到音乐曲目等任务。虽然这种研究在一定程度上仍然是人为的（通常没有实际购买），但此类评估似乎比上述离线实验更贴近现实。总的来说，鉴于CRS是一个需要支持复杂用户交互的系统，仅依赖离线实验似乎过于局限，除非是针对某些子任务。

最后，需要更多研究来理解：（i）人类在对话中如何相互推荐，以及（ii）用户如何与智能助手交互（例如，他们赋予智能助手何种智能以及他们的期望是什么）。与这些问题相关的一些方面在[29, 65, 108, 165]中进行了讨论。关于人类如何相互交谈，[13]和[29]中进行了相关分析。在[13]中，作者基于对话分析领域的见解，在其技术提案中实现了典型的现实世界对话模式，尽管形式较为受限。总的来说，还需要更多工作来理解当某些通信模式（如系统推荐的解释）不被支持时，对系统质量感知的影响，正如许多研究系统的情况一样。

7 OUTLOOK

我们的研究表明，近年来对话推荐系统（CRS）领域的研究显著增加，其中最新的方法依赖于机器学习技术（特别是深度学习）和基于自然语言的交互。尽管取得了这些进展，但许多研究问题仍然悬而未决，正如本文讨论部分所概述的那样。在这最后一节中，我们简要讨论四个更普遍的研究方向。

第一个问题是：“在给定任务中，哪种交互模式最能支持用户？”虽然语音和书面自然语言最近变得更加流行，但需要更多研究来理解哪种模式适合给定的任务和当前情况，或者是否应向用户提供替代模式。一个有趣的研究方向还在于对用户非语言交流行为的解释。此外，完全基于语音的CRS在在一个交互周期内呈现整套推荐时存在局限性。在这种情况下，可能需要总结一组推荐，因为在大多数情况下，CRS向用户读出多个选项可能没有意义。

其次，我们提出：“非标准应用环境中的挑战和要求是什么？”目前，大多数现有研究集中在交互式网络或移动应用程序上，无论是使用表单和按钮还是在聊天机器人应用程序中使用自然语言输入。一些讨论的工作超越了这些场景，考虑了CRS可以使用的替代环境，例如在实体商店、汽车、自助服务终端解决方案中，或作为（人形）机器人的功能。然而，到目前为止，对于这些应用场景的具体要求、挑战和机遇，以及决定此类系统采用和价值的因素，知之甚少。关于使用场景，我们调查中讨论的大多数研究工作都集中在一对一的交流上。然而，还有一些尚未探索的场景，例如CRS支持群体决策过程[1, 103]。

第三个问题是：“我们可以从对话理论中学到什么？”参见[141]。关于CRS的基础和采用因素，只有很少的工作基于对话分析、传播理论或相关领域的概念和见解。在一些工作中，至少以定性或轶事的方式讨论了现实世界推荐对话中的某些沟通模式。然而，目前似乎主要缺乏的是对什么使CRS真正有帮助、用户对这样的系统有什么期望、什么使他们失败[95]，以及我们应该或必须在系统中支持哪些意图的更清晰理解。解释通常被认为是令人信服的对话的主要特征，但这些方面并没有得到很多探索。此外，需要更多研究来理解增加CRS采用的机制，例如通过增加用户的信任和发展亲密关系[72]，或通过将沟通风格（例如关于主动性和语言）适应个别用户。

最后，从技术和方法论的角度，我们提出：“通过纯端到端学习方法，即创建除了项目数据库外仅以过去对话语料库为输入的系统，我们能走多远？”近年来，自然语言处理技术取得了巨大进展，但问题是今天基于学习的CRS是否真的有用，参见[59]。部分问题在于我们如何评估此类系统。像BLEU这样的计算指标只能回答问题的某些方面。但即使在已审查的论文中，人类评估有时也不够深入，特别是当新提出的系统由少数人类评委相对于之前的系统进行评估时。因此，我们应该重新审视我们的评估实践，并研究用户实际上对CRS的期望是什么，他们对误解或糟糕推荐的容忍度如何，我们如何影响这些期望，以及这些系统在绝对尺度上被认为有多大用处。从技术上讲，将学习技术与其他类型的结构化知识结合起来，似乎是未来更可用、更可靠和更可预测的对话推荐系统的关键。