前言
- 本文针对对话式推荐任务，提出基于图结构进行路径推理实现交互推荐。
- project： https://cpr-conv-rec.github.io/manual.html/
对话推荐系统（CRS）通过直接向用户询问其在商品上的偏好属性，解决了传统推荐中存在的局限。但是，现有的CRS方法没有充分利用这种优势-它们仅以隐式方式使用属性反馈(attributes feedback)，例如更新潜在用户表示形式。在本文提出了会话路径推理（Conversation Path Reasoning, CPR），将推荐建模为转换图上的交互式路径推理问题。它通过遵循用户反馈，以显式方式利用用户偏爱的属性来遍历属性顶点。通过利用图结构，CPR可以删减许多不相关的候选属性，从而有更多机会击中用户偏爱的属性。为了演示CPR的工作原理，提出了一个简单而有效的实例（SCPR），对多轮对话推荐方案进行实证研究，这是迄今为止最现实的CRS设置，它考虑了多轮询问属性和推荐物品
引言部分
- 传统方法虽然被证明是成功的，但它在推荐的过程中受到被动获取用户反馈的固有局限性的困扰。这种信息不对称使得难以获得动态且细粒度的用户偏好，从而阻止了系统提供准确且可解释的推荐服务。
- CRS被设想为对话系统和推荐系统的深层组成[。当使用自然语言与用户进行交互时，它会提出推荐，并且可以主动询问用户他/她是否喜欢商品属性。
- CRS具有利用用户偏爱的属性作为可解释原因进行动态且可解释的推荐的天然优势。
- 但是，现有作品仅通过将属性映射到潜在空间中来隐式利用属性反馈，我们认为这并未充分利用属性反馈的优势。例如，一些研究一旦获得关于属性的用户反馈，就更新隐含用户嵌入(Latent embeddings)。
这项工作的主要假设（key hypothesis）: 利用属性偏好的更明确的方法可以更好地发扬CRS的优势。为此，我们提出了一种新颖的会话推荐框架，称为“会话路径推理。
- 将会话推荐建模为在用户项-属性图交互中查找路径的过程。图1显示了一个示例。右图中的顶点代表用户，项目和属性以及其他相关实体。两个顶点之间的边表示它们之间的关系.
例如，用户-物品边指示用户已与该项目进行交互，用户-属性边指示用户在对话会话中确认了属性。对话会话（conversation session）在图中表示为游走(walk)。它从用户顶点开始，并在图中移动，目标是达到用户喜欢作为目标的一个或多个物品顶点。游走是由用户通过对话进行导航的。这意味着，在每个步骤中，系统都需要与用户进行交互，以找出要走到哪个顶点，并根据用户的响应采取措施。
MULTI-ROUND CONVERSATIONAL RECOMMENDATION SCENARIO 多回合对话推荐场景
本文遵循多回合对话推荐（MCR）方案，因为它是迄今为止研究中最现实的设置。 在MCR设置中，CRS可以自由地询问属性或提出推荐。 我们使用回合(round)来强调一次推荐试验。
- single-round:，系统多次询问属性，然后仅进行一次推荐**，此后，无论推荐是否成功，对话会话都会结束。
- Multi-round: 多次询问属性，进行多次推荐。
物品v与一组属性相关联。 该属性描述项目的某些属性。 例如，在音乐艺术家推荐域中（例如，在lastFM数据集中），物品是音乐艺术家，并且属性可以是诸如爵士，古典的描述。项目和属性由数据集提供。在对话会话期间，CRS通过询问用户是否喜欢特定的属性来获得用户的细粒度偏好。 基于这样的对话，CRS旨在在最短的对话时间内提供准确的推荐。
Multi-round的CRS推荐流程如下所示：可以将single-round等其他推荐视为MCR的一种特例，总体上这是比较完整的推荐设置。
以上MCR场景有两个假设：
- 假定用户通过不带任何保留地指定属性来清楚地表达自己的偏好，并且包含首选属性的物品在数据集中足够多。在此假设下，CRS将用户接受的属性作为有力的指标。例如，它仅考虑包含他接受的所有属性的所有项目（算法1中的第2行和第8行）。这是因为包含所有首选属性的物品的优先级高于不具有的优先级。由于这样优先级较高的物品就足够了，因此忽略其他候选项目可以合理地简化此问题。
- 假设CRS没有处理强烈的负面反馈。这意味着，如果用户拒绝询问的属性，则CRS不会区分用户是否在乎或讨厌该属性。这是因为在当前数据中很难获得这样的负反馈，因此很难在实验环境中进行仿真。因此，CRS会同等对待所有拒绝属性does not care，仅从候选集中删除属性，而无需采取其他措施，例如删除所有包含拒绝属性的物品。
关键的研究问题:
（1）推荐哪些推荐？
（2）询问哪个属性？
（3）什么时候问属性，什么时候提出推荐？
模型方法
1. CPR Framework
构图：节点包括用户、物品、以及属性。在MCR中，系统将属性视为偏好反馈。为了明确地利用这些反馈，CPR在属性顶点上执行遍历：
CPR维护一个活动路径P(active path)，该活动路径P包含按时间顺序由用户确认的属性（即Pu中的所有属性），并在图上探索下一个要遍历的属性顶点。
- 【无向不重复访问】CPR不会访问以前访问过的属性，也不会考虑边的方向。
- CPR遍历与基于图的推荐中遍历所有类型的顶点不同。CPR限制在属性上行走，会带来两个好处：首先，它强调了将属性作为推荐的明确原因的重要性。其次，它使行走过程更加简洁，消除了不必要的漫长推理路径中的不确定性，而不确定性可能导致错误累积。
假设当前活动路径：系统停留在处，并将查找要行走的下一个属性顶点。 此过程可以分解为三个步骤：reasoning(推理)，consultation(咨询)和transition(过渡)
- reasoning
一轮交互的开始， 当用户初始化或确认属性时触发。 在此步骤中，CPR对项目和属性进行评分，从而解决推荐哪些项目以及要询问哪个属性的问题。 在MCR的上下文中，CPR将评分表示为图上的消息传播。 由于属性和物品的评分是相互依赖的，因此采用了一种交替优化策略，以一种异步的方式对它们进行了优化，这已被证明是有效的。
首先，交替优化将消息从属性传播到项目，以对物品进行评分。 具体来说，路径P中的所有属性（即∀pi∈Pu）与用户顶点u一起将消息传播到中的候选物品。每个项目的评分功能可以是传统推荐模型的任何实现，抽象为
其次，候选物品又将消息传播到候选属性。 在第一步中计算出更新的物品分数（即sv）后，这些物品会提供其他信息，以找到适当的属性来询问用户，询问可以减少项目评分不确定性的属性。 具体来说，由于图结构的自然约束，CPR仅考虑到相邻属性的转移：如果属性pt和aat之间的最短路径不包含任何其他属性，则aat是ofpt的相邻属性。正式地，在CPR中，候选属性集
这种相邻的属性约束带来两个好处。 （1）在推荐方面，它大大减少了选择要询问哪个属性的搜索空间。（2）在对话方面，限制相邻属性会使对话更加连贯。 在语言学中，两个实体在任意两个相邻话语中越接近，对话将越连贯。
- Consultation.
此步骤的目的是确定是否要询问属性或推荐物品，以在最少的时间内获得成功的推荐为目标。 我们将其作为强化学习（RL）问题来解决。 具体而言，期望策略函数π（s）基于全局对话状态s做出决策，该全局对话状态s可以包括对成功推荐有用的任何信息，例如对话历史记录，候选项目的信息。 策略函数包含两个选择：ask或rec，即执行推荐还是依次询问属性。 如果RL决定为ask，则我们直接从Pcand中获得最高得分的属性，其中的得分是等式中所定义的sp。 （2）。 否则，我们建议根据等式中定义的sv分数，从Vcand推荐前k个物品。
这里的RL设计与现有的会话推荐系统EAR CRM 的主要区别在于：尽管他们也使用RL学习策略网络，但他们的策略是决定要询问哪个属性，动作空间的大小为| P |。 + 1，其中| P | 表示属性的数量。 这极大地增加了很好地学习策略的难度，尤其是对于较大的| P |，当动作空间较大时，RL很难训练[4]。 相反，本文RL的动作空间大小为2，易于训练。
- Transition.
用户确认询问的属性pt后，将触发转换步骤。 CPR首先执行从最后确认的属性pt-1到pt的遍历，形成扩展路径。 然后，将pt添加到偏好属性集Pu。 因此，候选属性集通过Pcand = AAt \（Pu∪Prej）进行更新，并且候选项集Vcand通过将直接链接到所有属性的项保留在更新的Pu中来进行更新。即对属性集和候选物品集进行更新。
2. SCPR Model
CPR的简单实现案例：
- Reasoning
物品评分生成方法
即属性对应的向量，是FM的一种改造形式
属性评分计算方法
推理步骤的另一个功能是根据当前系统状态决定哪个属性值得询问。 一种预期的策略是找到一种可以更好地消除项目不确定性的策略。 信息熵已被证明是一种不确定性估计的有效方法，这里也采用信息熵来评估属性：具体采用了一个加权方法：使用sigmoid函数将物品评分进行归一化处理，基于归一化的物品评分计算概率。
与平均对待每个物品的标准熵不同，在此处使用的加权熵为属性评分中的重要物品（即Vp中得分较高的项目）分配了更高的权重。 如果没有消息传播到属性，则将其熵定义为0。
- Consultation RL Policy
使用标准Deep Q-learning来优化。策略网络Policy network 将状态向量s作为输入，并输出两个动作的值Q（s，a），指示对ask或rec的估计奖励。 系统将始终选择具有较高估计报酬的动作:
对对话历史记录进行编码，有利于指导系统更智能地运行，例如，如果多次轮流接受要求的属性，则可能是推荐的合适时机。 编码候选项目集的大小。 如[13]所讨论的，当候选物品较少时，更容易做出成功的推荐。
设置五种奖励，即（1）rrec_suc，当推荐成功时为强阳性奖励，（2）rrec_fail，当推荐失败时为强否定奖励，（3）rask_suc，a 当用户接受一个询问的属性时会产生轻微的正向奖励；（4）当用户拒绝一个询问的属性时会产生一个负奖励；（5）如果会话达到最大轮数，则会给用户带来强烈的负面奖励。 累计奖励是这五个奖励的加权和。
实验情况
数据集设置
LastFM用来评估二分类问题方案(用户使用yes或no优先选择属性）。 为了简化建模，手动将相关属性合并为33个粗粒度属性。 Yelp数据集是为枚举问题设计的，用户可以在一个类别下选择多个属性，手动建立了一个2层分类法，有29个第一层类别和590个第二层属性。 文中还考虑使用原始属性（修剪频率<10个属性）的设置，分别将它们表示为LastFM *（包含8438个属性）和Yelp *（包含590个属性）。实验设置
参数情况：
数据集划分： 7:1.5:1.5；
topK :10;
最大对话轮： 15；
训练过程由两部分组成：（1）在推理步骤中对物品的评分功能进行离线训练。 使用训练集中的历史点击记录来离线优化FM模型。 目标是为每个用户为点击的项目分配更高的分数。 我们在附录B中详细说明了这些细节，还请读者参考原始论文[13]以获取更多信息。 用于离线训练的所有超参数均与[13]相同。 （2）在咨询步骤中使用的在线强化学习训练，使用用户模拟器与用户互动，以使用验证集来训练策略网络。
用户模拟器 User simulator
由于CRS是一个交互式系统，因此需要通过与用户进行交互来对其进行训练和评估，构建用用户模拟器是一种常见的做法。该模拟器针对验证集（用于训练）和测试集（用于测试）中的一个用户物品（u，v）交互记录模拟一个会话会话。在给定的一个session中，用户u的偏好由物品v确定：（1）当系统生成推荐物品列表时，只有当列表中包含项v时，他才会接受； （2）当系统要求一个属性时，只有在第v物品中包含该属性时，他才会确认自己喜欢它。
具体来说，给定数据集中的用户-物品交互（u，v），将物品v视为要寻求的真实物品，并将其属性视为用户在此会话中偏爱的属性oracle集合。 首先，我们从属性oracle集合中随机选择一个属性，来初始化用户会话。 然后，会话进入第2节中介绍过程的循环。我们将会话的最大对话轮次T设置为15，并将推荐列表长度Vt标准化为10。
无可否认，这种模拟有很多局限性，但这在当前阶段是最实际和现实的。这种模拟的一个主要问题是用户可能“错误地”拒绝实际上被他喜欢但未被观察到的物品因此未被他点击。但是，由于几乎没有合适的曝光数据，因此很难解决。有人可能会建议将测试集中的所有用户项目互动都视为一个会话的积极实例，我们也放弃使用它，因为CRS的目的是捕获用户当前的特定偏好，而这种偏好可能会偏离他的总体兴趣。由于我们的主要重点是图推理策略，因此我们使用模板进行对话。
- 评估指标
对话成功率(Success Rate@t)
平均对话轮次(Average Turn)
case study
小结
本文介绍了基于图推理进行CRS交互的方法CPR，主要研究点在于多轮推荐上，采用模板的方式生成对话。总体逻辑清晰，CPR实现上基于FM进行改造，并用RL来进行多轮对话的开展，实验细节说明也比较清晰，值得借鉴。
END
本人所有文章均为原创，欢迎转载，请注明文章出处 。百度和各类采集站皆不可信，搜索请谨慎鉴别。技术类文章一般都有时效性，本人习惯不定期对自己的博文进行修正和更新，因此请访问本人主页查看最新信息https://www.jianshu.com/u/40d14973d97c