最近对于会话推荐有了新的兴趣
文章题目：
A Survey on Session-based Recommender Systems
0. 前言
提供了一个统一的框架来对SBRSs研究进行分类
SBRS的统一问题陈述，其中SBRS建立在正式概念之上：用户、项目、动作、交互和会话我们全面概述了会话数据的独特特性以及由此带来的SBRSs挑战
会话任务方法进行了系统的分类和比较
全面了解如何应对挑战以及SBRS领域取得了哪些进展简要介绍了SBRSs的每一类方法以及关键技术细节
讨论了SBRS研究中存在的问题和前景
1. 序列推荐和会话推荐的区别
作者对于Boundary解释
是指在事务事件中启动和结束特定会话的开始-结束交互对
会话 可以分为 有序会话 和 无序对话
这个session 内 交互 内item 是不是按顺序分布的来区分是否为 无序有序
对于边界间隔 session 有很多个 而 序列 只有单一一个
对于 其 嵌入的主要关系
基于 会话的 是 共现关系 而 基于 序列的 是 顺序依赖关系
2. 会话推荐
2.1 目的
会话推荐需要注意attention
- SBRS旨在通过学习会话内或会话间的依赖关系，预测给定已知部分的会话的未知部分（例如，一个项目或一批项目），或给定历史会话的未来会话（例如，下一个篮子）。
- 原则上，SBRS不一定依赖会话内的顺序信息，但对于有序会话，可以利用自然存在的顺序依赖性进行建议。
2.2 框架
主要工作分为三个子领域
其子领域 可以分为
- 下一次交互推荐
- 下一次部分会话推荐（即 下一个会话出现了一部分 预测剩余的部分）
- 下一次会话推荐
Point-Of-Interest (POI) 生词
其实 在框架体现中 可以看出 下一个项目的推荐是 最多的还是一个交互的推荐
2.3 相关的研究
作者认为现有的研究没有发现任何系统地将这一研究领域正规化的研究，或全面分析会话数据的独特特征和SBRS所面临的关键挑战。更不用说提供一个深入的的总结，或详细说明该领域存在的公开研究问题。
对于 相关的研究 习惯将 RS 和 SBRS 混为一谈 且 特别针对 SBRS 的研究特别少。工作主要集中在序列感知RSs上，只讨论了一小部分基于有序会话数据的SBRS工作，而忽略了基于无序会话的SBRS。
2.4 会话推荐的主要符号
一个表征通常被指定为一个潜在的向量
通过这里 可以看出 不同于 序列推荐的 ui 组合
在会话推荐中 更倾向于 UVO 这样的三元组组合
2.5 SBRS问题陈述
一个RS可以被看作是一个系统[8, 9]，它由多个基本实体组成，包括用户。物品和它们的行为，例如，用户与物品的互动。这些基本实体和行为构成了会话的核心成分，也就是SBRS的核心实体。因此，我们首先介绍这些实体和行为的定义和属性，然后在此基础上定义SBRS问题。基于它们的定义。这些定义和属性将被进一步用于SBRS的特征和这些定义和属性将进一步用于SBRSs的特征和分类，等等。
2.5.1 用户表示（与序列推荐有些不同）
在SBRS中，用户是对物品（如产品）采取行动的主体，如点击、购买。并接受推荐结果。让u表示一个用户，每个用户都有一个唯一的ID和一组描述她的属性，例如，一个用户的性别，它有多个值。如：男性和女性。一个用户的属性可能会影响她对项目的操作，并进一步影响相应的会话。
除了可以明显观察到的显性属性外，还有一些隐性属性，它们反映了用户的内部状态。例如她的情绪和意图，也可能对她的行为产生重大影响。所有的用户共同组成了用户集，即U = {u1,u2,. . . ,u |U |}。需要注意的是，一个会话的用户信息可能并不总是可用的，原因有二：
(1)由于隐私保护，它不会被记录下来；
(2)一些用户在与在线平台互动时不会登录 如amazon.com。因此，会话成为匿名的
2.5.2 item表示
v表示一个项目，该项目与唯一ID和一组属性相关联，以提供项目的描述信息，例如项目的类别和价格。数据集中的所有项目构成项目集，即V={v1，v2，…，V | V |} 没什么好说的 很简单
2.5.3 动作表示
用户通常在会话中对某个项目执行操作，例如单击某个项目。让a表示一个动作，该动作与一个唯一ID和一组属性相关联，以提供其属性信息，例如动作的类型，并具有多个值，例如单击、查看和购买。请注意，某些操作可能与特定项目无关，例如搜索操作或目录导航操作。但如参考文献中所述，它们仍可能为SBRS提供有用的信息
2.5.4 交互
| user | 交互 |
|---|---|
| available | o = <u, v, a> |
| no available | o = <v, a> |
| no available and action only one | o = |
2.5.5 会话
会话包含交互!!
s = {o1,o2, . . . ,o |s |}.
注意一点 单一会话中 可能会出现重复的交互
每一个对话 都与一组属性相关联 例如 持续时间s （ 20分钟或40分钟 ）
| 属性 | 定义与影响 |
|---|---|
| session length | 会话的长度定义为会话中包含的交互总数。这是会话的一个基本属性 |
| internal order（内部秩序） | 一个会话的内部秩序指的是其内部交互的秩序。通常情况下，在不同的会话中存在着不同类型的灵活秩序，即无秩序、灵活秩序和秩序。 |
| action type | 在现实世界中，一些会话只包含一种类型的操作，例如购买，而其他会话可能包含多种类型的操作，例如单击、购买。会话中动作类型的数量决定会话内依赖关系是否是同质的（基于单个动作）或异构（基于多种类型的操作），这对于准确的建议很重要 |
| user information | 用户信息在连接同一用户在不同时间发生的会话方面起着重要作用，因此其可用性决定了为特定用户跨多个会话建模长期个性化偏好的可能性。用户信息的属性是指会话中用户信息的可用性。实际上，SBRS最初被提议用于处理用户信息不可用的匿名会话 |
| session-data structure | 是指与会话相关的层次结构组成的多层次结构。交互层由每个会话中的交互组成，而会话层则由当前用户的多个历史会话组成。（即区分会话和交互） |
这个图 可以看出 会话的第五个属性 ： 会话的层次结构
2.6 问题定义
2.6.1 输入
(1) 当前会话的已知部分（即已发生的交互的列表），这是SBRS的输入。它只为下一个交互（项目）建立会话内的依赖关系，或下一个部分会话的建议（参见第2.2节）。
(2) 已知的历史会话列表，它是主要为下一个会话（如abasket）推荐建立会话间依赖关系模型
(3) 前两者的组合，这是SBRSs的输入为下一次交互的推荐建立会话内和会话间依赖关系的模型。或下一个部分会话建议。
在特定情况下，当前会话或历史会话的输入部分可以是匿名或非匿名、有序或无序的，并具有单一或多种类型的操作。根据我们的观察，大多数现有的SBRS假设输入会话是有序的，并且具有单一类型的操作
2.6.2 输出
SBRS的目标是根据给定的会话上下文，即已知的会话信息，提出建议
（1）在下一次交互建议中，输出是备选交互（项目）的列表，按最佳匹配排序为会话中的下一次交互（项目）；
（2） 在下一部分会话建议中，输出是完成当前会话的交互（项目）列表；
（3）在下一次会议建议中，输出是组成下一次会议的补充互动（项目）列表
2.7 挑战
针对2.5.5 对于会话提出的5个属性 提出了相对应的5个挑战
2.7.1 会话长度
根据会话长度，会话大致可分为三种类型：长会话、中会话和短会话，而长会话、中会话和短会话的具体定义可能因特定数据集而异
| 会话 | 描述 | 挑战 |
|---|---|---|
| 长会话 | 一个长会话包含相对较多的交互，例如超过10次。总的来说，通过更多的互动，长时间的会话可以提供更多的上下文信息，以获得更准确的建议。然而，由于用户行为的不确定性，长会话更有可能包含与其中其他交互无关的随机交互。这会带来嘈杂的信息，从而降低建议的性能 | 第一个挑战是如何有效地减少不相关交互中的噪声信息。另一个挑战是如何有效地学习复杂的依赖关系以获得更好的推荐性能 |
| 中会话 | 中等会话通常包含中等数量的交互，例如4到9次。根据我们对电子商务行业交易记录生成的会话数据的观察，中间会话是最常见的情况。与长会话和短会话相比，中等会话不太可能包含太多不相关的交互，而它通常包含基于会话的推荐（SBR）所需的上下文信息。 | 即如何有效地提取相关和准确的上下文信息以获得准确的建议。 |
| 短对话 | 一个简短的会话包含非常有限的交互，例如，通常少于4次，导致可供推荐的信息有限。例如，在由两个交互组成的脱机匿名会话中，可以用来推荐第二个交互（项目）的唯一上下文信息是会话中的第一个交互。一种极端情况是建议会话的第一次交互。 | 如何在有限的背景信息下有效地提出建议 |
2.7.2 内部顺序 （会话内是否存在顺序）
| 内部顺序 | 描述 | 挑战 |
|---|---|---|
| 无序对话 | 无序会话包含的交互之间没有任何时间顺序，也就是说，会话中的交互发生得早或晚没有区别。因此，通常使用的序列模型不适用。与顺序依赖相比，基于共现的依赖通常相对较弱且模糊，更难学习。此外，交互之间大多数基于共现的依赖关系都是集体依赖关系，即会话中的多个上下文交互协同导致下一个交互的发生，而下一个交互更难捕获。 | 如何有效地学习交互之间相对较弱和模糊的依赖关系，尤其是那些集体依赖关系 |
| 有序对话 | 有序会话包含多个具有严格顺序的交互，它们之间通常存在强的顺序依赖关系 | 长顺序会话中有效学习级联的长期顺序依赖是一个挑战 |
| 灵活安排 | 灵活排序的会话既不是完全无序的，也不是完全有序的，即会话的某些部分是有序的，而其他部分不是 须仔细考虑和准确了解灵活排序会话中的复杂依赖关系 | 来自于如何有效地学习复杂和混合的依赖关系，即有序交互之间的顺序依赖关系和无序交互之间的非顺序依赖关系 |
2.7.3 动作类型
| 动作类型 | 描述 | 挑战 |
|---|---|---|
| 单一动作 | 单一类型的操作会话仅包括一种类型的操作，例如单击项目，因此只有一种类型的依赖关系来自同一类型的操作，这相对容易学习 | 很好学习 |
| 多种动作 | 一个多类型的动作会话包括多种类型的动作[54]，从而导致多种类型的交互。在多类型操作会话中存在复杂的依赖关系。具体来说，依赖性不仅存在于同一类型的交互上（例如，点击项目），还存在于不同类型的交互上（例如，点击和购买）。 | 如何有效准确地了解行动内和行动间类型的依赖关系，以获得准确的建议 |
2.7.4 用户信息
| 用户信息 | 描述 | 挑战 |
|---|---|---|
| 不匿名 | 非匿名会话包含与相关用户信息的非匿名交互，从而支持同一用户在不同时间生成的不同会话之间的连接。这使得了解用户的长期偏好以及其在会话中的演变成为可能 | 准确地了解个性化的长期偏好，而不是多个非匿名会话，这是一个相当具有挑战性的问题 |
| 匿名 | 在匿名会话中，由于缺少连接同一用户生成的多个会话的用户信息，因此几乎不可能为当前会话收集以前的历史会话。因此，只有来自当前会话的上下文信息才能用于建议。 | 利用有限的上下文信息精确捕获用户的个性化偏好以提供准确的推荐是一个挑战 |
2.7.5 会话数据结构
| 数据结构 | 描述 | 挑战 |
|---|---|---|
| 单级会话 | 单级会话数据集通常是一组匿名会话，其中每个会话由多个没有属性信息或历史会话信息的交互组成。在这种情况下，建议只能使用单级依赖项，即会话内的交互依赖项。因此，由于缺乏其他级别的辅助信息，基于单级别会话数据构建的SBRS很容易受到冷启动或数据稀疏问题的影响 | 即当只有交互依赖关系可用时，如何克服冷启动和稀疏性问题以获得准确的建议 |
| 多级会话 | 多级会话数据涉及至少两个级别的层次结构，即交互级别加属性级别和/或会话级别。在这种情况下，每个级别内和不同级别之间的依赖关系都会影响后续的建议。例如，多个项目的类别（属性级别）可能会影响这些项目是否会在一个会话中一起购买（交互级别） | 如何全面了解级别内和级别间的依赖关系以获得有效和准确的建议，成为构建在多级会话数据上的SBRS面临的一个关键挑战 |
3 SBRS方法的分类和比较
分类部分 这里写了个大概 还得仔细去看
三大方法为 常规SRS方法 潜在特征方法 深度神经网络方法
3.1 常规方法
3.2 SBRSs的潜在表示方法
SBRSs的潜在表示方法首先使用浅层模型为会话内的每个交互构建低维潜在表示。学习到的信息表示对这些交互之间的依赖关系进行编码，然后将用于后续基于会话的建议
3.3 SBRSs的深度神经网络方法
