《Learning to Retrieve User Behaviors for Click-through Rate Estimation》
CTR estimation
在现代在线个性化服务中起着至关重要的作用。通过建模用户行为序列来捕获用户兴趣的变化,对构建准确的 CTR estimation
模型至关重要。然而,随着用户在在线平台上积累了大量的behavior
数据,当前的 CTR
模型必须截断用户行为序列并利用最近的behavior
,这导致一个问题,即诸如周期性(periodicity
)或长期依赖性(long-term dependency
)之类的序列模式(sequential patterns
)不被包含在最近的behavior
中,而是包含在遥远的历史中。然而,直接使用整个用户序列并对其进行建模并非易事,原因有二:
首先,非常长的输入序列会使在线 inference time
和系统负载变得不可行。
其次,非常长的序列包含很多噪音,因此 CTR
模型很难有效地捕获有用的模式。
为了解决这个问题,我们从 input data
的角度来考虑它,而不是设计更精巧但更复杂的模型。由于整个用户行为序列包含很多噪音,因此没有必要输入整个序列。相反,我们可以只检索其中的一小部分作为 CTR
模型的输入。在本文中,我们提出了用户行为检索(User Behavior Retrieval: UBR
)框架,旨在根据每个 CTR estimation request
来学习从而检索最 informative
的user behavior
。只检索一小部分behavior
可以缓解 utilizing very long sequences
的两个问题(即推理效率和噪声输入)。UBR
的显著特性在于它支持任意且可学习的检索函数,而不是使用固定的且预定义的函数,这与当前 retrieval-based
的方法不同。
在三个大型真实数据集上的离线评估证明了 UBR
框架的优越性和有效性。我们进一步在 Huawei App Store
部署了 UBR
,在线 A/B test
中实现了 6.6%
的 eCPM
增益,现在服务于 Huawei App Store
广告场景的主要流量。
CTR estimation
在当今的在线个性化平台(例如电商、在线广告、推荐系统)中起着关键作用,其目标是预测用户在特定上下文中点击特定 item
的概率。近年来,基于用户行为序列的 CTR estimation
模型引起了工业界和学术界越来越多的关注。这些基于user behavior
的 CTR
模型旨在捕获包含在user behavior
中的丰富的时间模式(temporal patterns
),并学习用户兴趣的变化,从而获得准确的 CTR estimations
。这些序列模式包括概念漂移(concept drifting
)、长期行为依赖性(long-term behavior dependency
)、周期性模式(periodic patterns
)等等。
Deep Interest Network: DIN
和 Deep Interest Evolution Network: DIEN
是在 CTR prediction
中,通过建模用户行为序列从而捕获用户兴趣的代表性模型。 DIN
结合了注意力机制来学习不同 user behaviors
的重要性,而 DIEN
利用 GRU
来捕获user behavior
的 dynamics
。其他 user behavior-based
的 CTR estimation
模型(《Behavior sequence transformer for e-commerce recommendation in alibaba》
、《Deep session interest network for click-through rate prediction》
)具有相似的动机和结构。
至于 CTR estimation
的类似文献,在序列推荐(sequential recommendation
)领域,有很多关于如何对用户行为序列进行建模的研究工作。有 RNN-based
的模型,如 GRU4Rec
、GRU4Rec+
;有 CNN-based
的模型,如 CaseR
;有 Transformer-based
的模型,如 SASRec
、TiSASRec
;还有 memory network-based
的模型。
随着在线个性化平台十多年的发展,平台上记录的user behavior
数量迅速增长。在淘宝上,仅在六个月内,就有 23%
的用户积累了超过 1,000
次behavior
(《Lifelong sequential modeling with personalized memorization for user response prediction》
)。尽管上述基于user behavior
的 CTR
模型取得了巨大成功,但它们无法处理非常长的用户序列。如 Figure 1
上半部分所示,仅使用最近的行为进行 CTR estimation
(通常为 50
或 100
)。但是,如果仅使用最近的行为,序列中可能不包含长期依赖性或周期性等序列模式(sequential patterns
)。一种直接的解决方案是将整个用户序列馈入到 CTR
模型中,但这不可行。它会给系统开销带来沉重的负担并牺牲推理效率。更糟糕的是,在非常长的行为序列中,这种做法会带来很多噪音。
为了解决上述问题,一种解决方案是设计具有更多参数和更大容量的复杂模型,以支持更长的用户行为序列作为输入,如 Figure 1
上半部分所示。HPMN
和 MIMN
是两种用于处理长序列建模的 memory network
架构。然而,这些模型非常复杂,需要大量的工程工作才能在现实世界的在线系统中实现和部署。尽管 HPMN
或 MIMN
可以处理包含大约 1,000
个behavior
的序列,但全量的用户序列通常要长得多。
与上述解决方案不同,我们尝试从数据角度解决问题,而不是设计更精巧但更复杂的模型。由于非常长的序列包含很多噪音,因此没有必要输入整个序列。相反,只有一小部分behavior
与 prediction
相关。因此,我们只需要检索相关的behavior
。检索到的behavior
取决于每个 CTR estimation request
。我们将每个 request
称为 prediction target
。如 Figure 1
所示,prediction target
由三部分组成,即 target user features
(职业、地理位置等)、target item features
(category
、品牌等)、以及相应的上下文特征(场景等)。然后,这些特征将被视为 query
,并被用于从整个用户序列中检索 behaviors
。检索系统的目标是学习检索最相关的 behavior data
,从而辅助特定的 request
的 prediction
(即 prediction target
)。这样的检索过程利用索引结构,以整个用户历史行为作为检索池(retrieval pool
),效率很高。为此,通过检索user behavior
,长的用户序列可以有效地纳入 CTR
模型,而不会引入太多噪音。
在本文中,我们提出了用于 CTR estimation
的 User Behavior Retrieval: UBR
框架,从而对非常长的用户行为序列进行建模。由于现实世界在线个性化平台中的检索池通常很大,我们将检索过程分为两个子过程:matching
和 ranking
,类似于信息检索系统。
对于matching
过程,通过访问存储 behaviors
的索引可以快速检索一组候选behavior
。此过程本质上是获取具有与 prediction target
所匹配特征的 behaviors
。
获得 candidate behaviors
后,ranking
函数根据 candidate behaviors
与 prediction target
的相关性对其进行排序,并返回 top-k
个behavior
。
然后,被检索到的 behaviors
可以被任意 CTR
模型使用。
本文的重点是整合可学习的参数化的检索函数,并提出相应的训练方法。在现有的 retrieval-based behavior models
中,检索函数总是采用某种预定义形式,例如特征匹配(《Retrieval and interaction machine for tabular data prediction》
)、内积 (《Search-based user interest modeling with lifelong sequential behavior data for click-through rate prediction》
)、余弦相似度(《Learn over past, evolve for future: Search-based time-aware recommendation with sequential behavior data》
)或汉明距离(《End-to-end user behavior retrieval in click-through Rate Prediction model》
)。检索函数是固定的,因此它们不够灵活;并且由于其 pre-defined form
所引入的 inductive bias
,可能导致次优性能。相反,在 UBR
框架中,我们使用 prediction
的性能作为信号来训练检索函数。behavior retrieval
过程本质上是获取相对于 prediction target
(即 CTR request
)的 top-ranked behaviors
。使用参数化的结构(例如 DNN
)作为 ranking metric
可以大大提高检索函数的容量和表达能力。为实现该目标,我们提出了三种 UBR
变体:
UBR-M
利用 REINFORCE
来优化 retrieval function
的 matching
过程。
UBR-R
使用 learning-to-rank: LTR
技术来优化 retrieval function
中的 ranking
过程。
UBR-MR
是上述变体的混合版本,其中matching
和 ranking
过程都得到了优化。
通过比较这些变体,我们得到了一些有趣的观察结果和有意义的见解,指导我们在实践中选择最佳变体。详细信息可参见实验章节。
本文的贡献可以总结如下:
对于长行为序列的建模,我们从数据角度提供了一种新的解决方案,即从整个用户序列中检索user behavior
。这是一个实用的解决方案,它使当前的 CTR
系统在受到严格的效率约束的情况下能够使用整个用户序列。
我们系统地数学化了 learning to retrieve user behaviors
的问题,并提出了一个有效的模型和相应的训练算法。UBR
是第一个支持可学习的任意检索函数(而不是预定义的检索函数)的工作。
我们提出了更强大的变体:UBR-R
和 UBR-MR
。它们采用了由 LTR
技术优化的可学习的 ranking
函数。我们进一步证明 LTR optimization
函数可以引导 optimization
方向,从而获得更准确的 CTR estimation
模型。它为我们的优化算法提供了理论保证。
UBR
有效且易于部署。离线实验表明,它达到了 SOTA
的性能。此外,UBR
已成功部署在 Huawei App Store
的广告场景中。在线 A/B test
期间,它实现了 6.6%
的平均 effective cost per mille: eCPM
(有效的每千次展示费用)的提升率。它现在服务于 Huawei App Store
的主要广告流量。
本文是其会议版本 《User behavior retrieval for click-through rate prediction》
(即,UBR4CTR
)的实质性扩展。期刊版本(本文)和会议文章(即 UBR4CTR
)之间的主要区别在于:
在本文中,我们提出 UBR-R
和 UBR-MR
作为 UBR
框架的更好实现,而不是会议文章中提出的框架(表示为 UBR-M
)。新版本加入了可学习的 ranking
函数,使检索模块更加强大。
我们提出了一个 LTR optimization objective
来训练参数化的 ranking
函数,而不是会议文章中使用的 REINFORCE
算法。我们进一步对 LTR objective function
进行了广泛的理论分析。
我们提供了与一些 retrieval-based
序列建模算法的比较实验的结果,这些算法比我们的会议文章更晚被提出。
UBR
已在实际应用中部署,而我们在会议版本中仅对公共数据集进行了实验。在工业数据集上进行的新实验验证了 UBR
可以与各种 CTR
模型结合使用。我们进一步提供了在线实验细节。这些事实表明,UBR
在实际应用中部署是高度可行的。
未来工作:对于未来的工作,我们的目标是将 UBR
扩展为一个更通用的框架,不仅可以从单个用户那里检索,还可以从其他相似的用户那里检索。当前的 UBR
框架仅从 target user
自身的 behaviors
中检索。来自其他相似用户或 items
的协同过滤信息可能会进一步提高 UBR
的性能。在这种情况下优化其效率是另一个重要方向。
在本节中,我们将问题公式化并引入符号。对于 CTR estimation
任务,有 item
构成的 item
集 user-item interactions
表示为
此外,每个 user-item interaction
都与相应的上下文一起发生。我们分别使用 timestamp
和其他的上下文特征。因此,每个数据点被公式化为 item
multi-field features
组成,其中
item
、以及上下文的第
item
、以及上下文的 feature fields
的数量。
为了建模用户不断变化的兴趣,我们将整个user behavior
历史组织为 behavior
,按 timestamp
升序排序。用户 behavior
item
注意,在
UBR4CTR
中,,包含了用户特征。
CTR estimation
的目标是根据 target user
target item
其中:behavior
作为 prediction
函数 noisy
的。它表示为:
其中:retrieval
函数,返回 behavior
。
无论 retrieval
函数 set of user behaviors
。相比之下,对于我们的 UBR
框架,CTR estimation
任务的公式为
其中:retrieval
函数,可以在给定 target item
informative
的user behavior
(注意, target user
UBR
能够根据不同的 target items
或上下文从而动态选择最合适的user behavior
,而不是像以前的工作那样使用静态和固定的 selection
策略。
我们在 Table 1
中总结了符号和相应的描述。
在本节中,我们介绍了 UBR
框架的基本架构。本节介绍的检索过程是 UBR
的 basic
实现,是不可学习的。但它构成了系统的骨干。一些模块可以用参数化的组件替换,从而自动优化 UBR
。可学习的组件的详细信息将在下一个章节中描述。
如 Figure 2
所示,UBR
由 retrieval
模块和 prediction
模块组成。
顾名思义,retrieval
模块负责根据 prediction target
从 user history archive
中检索 behaviors
。 prediction target
由 CTR prediction request
中的 user, item, and context features
组成。prediction target
被用作 query
从而从 user history archive
中执行搜索。
retrieval engine
检索出一部分 behaviors
,这些被检索到的 behaviors
被馈入到 prediction
模块。prediction
模块由两部分组成。
第一部分是 aggregation
网络,它将学习 retrieved behaviors
的一个 unified representation
。该 aggregated representation
可以与其他特征组合起来并输入到任意 CTR
模型中,
第二部分是这个CTR
模型。由于 CTR
模型可以是任意结构,因此 UBR
具有很高的灵活性,可以与现有的 CTR estimation
系统一起部署。
由于检索 user behaviors
类似于检索 recommender system literature
的 items
,我们使用 matching and ranking
来划分整个检索过程。
matching
子模块通过访问索引结构从而快速获取 candidate behavior
的一个集合。
然后,接下来的 ranking
子模块将计算每个behavior
的分数,从而返回 top-k behaviors
。
matching
子模块的目的是:通过快速获取 candidates
的一个小集合,从而来降低计算复杂度。为了实现此目的,我们选择将其实现为 index accessing
过程。
倒排索引(Inverted Index
):作为典型的搜索引擎系统,我们将每个 user behavior
视为一个文档,将每个特征视为一个 term
。 user behavior
以倒排索引的方式存储。如 Figure 3
所示,我们以一条 behavior
记录 user id, category id, brand id, purchase day, and item price
。在特征工程过程中,原始特征全部重新映射到 unique id
。numerical
特征被离散化,然后重新映射。user id
(“ID-1”
)用作第一个索引,因为我们需要获取用户behaviors
,而其他 remapped features
则以倒排索引的方式作为第二个索引。behavior
posting lists
中。我们对每条behavior record
遵循相同的协议并构建倒排索引。
即,两层索引结构:最外层是
user-id
,这一层索引将保存每个用户的所有行为。第二层是不同的field
,给定用户的不同behavior
将根据特征取值的不同放入不同的索引。
query
:prediction target
query
。retrieval
的 query
其中:
注意,这里不包含用户特征
。但是, UBR4CTR
中包含了用户特征,但是不包含 user-id
特征。
matching
子模块本质上是一个特征匹配的布尔搜索过程。用户 behaviors
都将被检索出来。
从 matching
子模块获取 candidate behaviors
后,我们执行 ranking
程序,从而返回 top-k
结果作为 final retrieved behaviors
。我们使用 BM25
来计算每个behavior
的得分,因为它是搜索引擎系统中广泛使用的 ranking
函数。
每个behavior
query
ranking score
定义为:
其中:
term frequency
)。根据 match
,其取值为 1
或 0
。
behavior
behavior
中的特征数量,因此所有behavior
都具有相同的长度 avgdl
代表平均的文档长度。
可以进一步化简为:
。似乎 参数没什么用? 考虑到
取值为 0
或1
,因此:因此
也没什么用?
IDF
定义为:
其中:behaviors
的总数,
IDF
项赋予常见特征比罕见特征更少的重要性。与常见特征相比,罕见特征意味着对用户偏好的更强信号,这是有道理的。
top-k behaviors
构成 retrieval set
,即 retrieval set
被下游 prediction
模块使用,如 Figure 2
所示。
在本节中,我们介绍 UBR
的 prediction
模块。在 prediction
模块中,所检索到的 user behaviors
被聚合起来,相应的 representation
与其他特征一起馈入到 CTR
模型中,如 Figure 2
所示。UBR
框架具有高度灵活性,因为它可以与任意 CTR prediction
模型一起使用,因此可以方便地部署到实际应用中。
Retrieved Behaviors
的聚合:为了聚合 retrieved behaviors
并获得全面的 representation
,我们使用注意力机制来聚合behavior representations
:
其中:
aggregated behavior representation
。
retrieved behavior
的 embedding
, embedding size
,
注意:在
UBR4CTR
中,,包含了用户特征。
attention
权重:
其中:
attention layer
的权重矩阵。
query
dense embedding
,它是 feature embeddings
的拼接。
注意:在
UBR4CTR
中,,包含了用户特征。
aggregated retrieved behaviors
的 comprehensive representation
prediction target
的其他特征一起输入到 CTR
模型中。
CTR Estimation Model
:UBR
可以配备任意的 CTR estimation
模型。在这里我们使用一个简单的 DNN
结构作为 CTR
模型,在实验章节,我们还基于其他工业级的 CTR
模型测试了性能。final prediction
的计算方式为:
其中:
user embedding
、item embedding
、context embedding
。
behavioral representation
,MLP
的参数。
由于我们的目标是准确地估计 CTR
,因此 prediction loss
的自然选择是广泛使用的交叉熵损失。带 L2
范数的 prediction loss
定义为:
其中:
prediction
模块的所有参数,包括 CTR estimation
模型中的参数、以及 aggregation
函数中的参数。
retrieved behaviors
。在优化 prediction
模块时,retrieval
模块是固定的。
prediction
模块通过使用 SGD
来最小化
在本节中,我们介绍如何使 retrieval system
成为参数化的和可学习的。我们提出了三种可学习的 UBR
变体:UBR-M
、UBR-R
和 UBR-MR
。
UBR-M
和UBR-R
,顾名思义,是将 matching/ranking
过程分别转换为一个 parametric and learnable function
。
UBR-MR
,是同时优化 matching
和 ranking
子模块的混合版本。
可学习的 UBR
变体与 prediction
模块一起训练。在训练 retrieval
模块时,prediction
模块是固定的,反之亦然。
我们将首先为可学习的 retrieval system
公式化 optimization
问题,然后给出 UBR
变体及其相应 optimization
的实现细节。
首先,我们为 retrieved behavior set
定义一个效用(utility
)。它表示一个 behavior set
有多 “有用”。
Utility
的定义:behavior set
non-positive scalar
),可以反映 prediction
模块使用 CTR estimation
的准确性。在实现上,我们使用 negative log-likelihood
的倒数作为效用函数,即:
其中:
效用越高, CTR
模型使用集合
retrieval
模块的 general objective
公式化为:
其中:retrieved behaviors
的底层概率分布。
令 optimization
旨在找到最好的 retrieval
函数,从而能够最大化 CTR
模型的期望准确率。在以下小节中,我们将介绍 UBR
的不同变体及其相应的 optimizations
。
可学习的 UBR
的第一个变体是 UBR-M
,它提出了一个可学习的 matching
函数。
UBR-M
的结构:为了将 matching
过程变成一个可学习的子模块,我们选择将 query generation
参数化为一个可学习的 feature selection
过程。它将从 query
match the behaviors
,而不是 Figure 4
所示,我们使用 self-attention network
来建模特征之间的交互和关系。具体来说,我们定义:
其中:embedding
。
自注意力机制定义为:
而 multi-head self-attention
定义为:
其中:head
数量;
然后,multi-head self-attention
的输出 multi-layer perceptron
:
相应特征被选择的概率通过取 sigmoid
函数获得:
其中:
然后我们根据这些概率对特征进行采样,从而得到所选的特征子集。
原来有
个特征,那么采样后有多少个特征?作者没说。
总而言之,UBR-M
使用 self-attentive feature selection function
来参数化 matching
子模块。至于 ranking
,UBR-M
仍然使用 BM25 ranking function
。
UBR-M Optimization
:由于上述 feature selection
函数通过使用概率来采样,从而涉及不确定性并且不可微,我们可以直接通过 REINFORCE
(《Simple statistical gradient-following algorithms for connectionist reinforcement learning》
)算法优化
我们给出了 retrieved behaviors
的概率 likelihood ratio
)来估计,如下所示:
其中:retrieved sets
。
UBR-M
的不确定性实际上来自 feature selection model
,我们可以得出:
其中:
当
因此,我们得到:
其中:
通过使用 REINFORCE
算法,可以在 prediction
模块固定的情况下优化 UBR-M
。
UBR-M
是我们在之前的文章 《User behavior retrieval for click-through rate prediction》
中提出的。虽然 UBR-M
提供了参数化的 retrieval
函数的实现,但它仍然是粗粒度的,因为特征对应的 posting list
(例如 Figure 3
中的 “T-shirt” list
)的所有 behaviors
可能会被完全删除,并且不会被 prediction
模块使用。此外,UBR-M
的 ranking
模型是固定的 BM25
函数,这可能不是最佳选择。我们希望模型能够自动学习合适的 ranking
函数。
matching
子模块本质上是为ranking
子模块缩小候选空间。实验结果表明,优化ranking
要比优化matching
取得更好的效果。而优化matching
的效果一般般。
mathcing
子模块也可以认为是一种ranking
:将未被匹配的behaviors
设置ranking score = 0
。
UBR
的第二种变体是 UBR-R
,它提出了一个可学习的 ranking
函数。
UBR-R
的结构:固定的 ranking
函数不灵活,无法捕获每个 behavior
与 query
之间的复杂关系。因此,我们需要一个可学习的ranking
函数。对于 UBR-R
,我们将 ranking
函数从确定性的 BM25
更改为参数化的函数,同时保留前面章节中描述的固定的 matching
过程。参数化的 ranking
函数定义为:
其中:
behavior
ranking score
。
MLP
。,
UBR-R Optimization
:由于 getting the top-k behaviors
的操作不可微,所以我们无法直接优化 ranking
函数的参数 optimization
转换为 LTR
问题,并将其用作 UBR-R
的优化函数。因为 LTR
是训练 ranking
函数最广泛的范式。
作为 LTR
问题,我们要排名的 "items"
本质上是一个包含 behaviors
的集合。总共有 matching
子模块的 behaviors
总数,这意味着我们有 behavior
集合。
如果我们将每个 behavior set
final retrieved behaviors
并将其输入到 prediction
模块,我们将得到效用 Figure 5
所示,CTR
模型给出的效用可以看作是 "relevance labels"
。ranking
函数 behavior sets
时的性能从而对 behavior sets
进行排名。
在接下来的内容中,我们将分析 LTR
目标函数之间的理论关系。我们证明对 LTR loss
进行优化可以优化方程
将原始问题转换为 LTR
任务:我们将 probabilistic choice model
定义为:选择 ranking score
成正比:
其中:
LTR objective function
的定义:给定 query
ranking list
其中:
sigmoid
函数 sigmoid
函数的输入为
desired and latent ranking
。
我们记 LTR
任务的 general optimization goal
。
定理:LTR objective function
其中:
并且:
定理的证明参考论文的附录。
由于定理的成立,原始的目标函数可以转换为最大化 LTR objective
LTR
技术来优化它。我们进一步给出 LTR loss
的实现细节。
实现细节:为了有效地 inference
,我们将 ranking
函数表述为:
其中:scoring
函数。
为了进行推理,我们可以只使用 top-k ranking behaviors
(使用 retrieved set
scores
。
我们使用lambda loss
(《The lambdaloss framework for ranking metric optimization》
)作为LTR loss
来优化UBR-R
:
其中:
由于我们关心的是 top-1 behavior set
,并且为了快速训练,我们将损失函数简化为:
其中:top-k behaviors
组成(使用 behavior set
且它的 ranking score
低于
虽然简化了,但是
仍然会非常耗时。读者猜测这里进行了采样,否则就是 ,复杂度太高。 实现方式:
对于每个样本,计算它的
query
。 然后计算每个
behavior
计算它的 score
。 然后选择
top-k scores
的个 behaviors
,得到,以及对应的 、 。注意,为了得到 ,需要进行一次 inference
。然后采样
组,每组随机采样 个 behaviors
,得到,以及对应的 、 。注意,这里需要进行 次 inference
。最后,计算
。
在以上章节中,我们分别讨论了如何优化 matching
子模块和 ranking
子模块。将它们放在一起并尝试同时优化两个子模块是合理的。两个子模块的目标是统一的:prediction
模块更好的预测准确率。因此,可以如 Algorithm 1
所示,同时优化 matching
和ranking
函数。
我们首先使用前面章节中描述的 fixed behavior retrieval system
对 prediction
模块进行预训练。由于 prediction
模块在 matching
和 ranking
子模块的训练过程中提供监督信号,因此首先对其进行热身并使其具有基本的判别能力非常重要。
之后,轮流训练 retrieval
模块(第 4-8
行)和 prediction
模块(第 9
行),直至收敛。
是每个子模块训练一个
epoch
再轮流、还是每个子模块训练一个batch
再轮流?作者未讲明这一点。UBR4CTR
是每个子模块训练一个epoch
,然后再训练另一个子模块一个epoch
。
如Algorithm 1
所示, matching
和 ranking
函数朝着同一目标一起优化。
本节分析了时间复杂度,并将我们的框架与现有的 retrieval-based
的 CTR
模型进行了比较。
我们关注 retrieval
过程的时间复杂度,因为它是 UBR
中最耗时的部分。
对于 UBR
,由于 matching
过程只是简单地访问索引,因此其时间是一个常数 feature fields
的数量,inverted index entry
的时间。
对于查找 top-k behaviors
的 ranking
过程,时间复杂度为 matching
子模块中获取的 candidate behavior set
的大小。因为评分过程的时间复杂度与列表长度成线性关系。
因此,UBR
的总复杂度为 UBR
带来的主要耗时是 GPU
或 CPU
在内存中计算。然而,大多数基于 behavior modeling
的 CTR
模型可能具有 user behaviors
。此外,可以使用快速存储、更快的数据访问系统(如 Redis
等)对
这只是
inference
的时间复杂度。而训练的时间复杂度相当高。
作为用于 CTR estimation
的 behavior modeling
的新研究方向,关于 retrieval-based
的 CTR
模型的研究很少。
最相似的模型是 SIM
。SIM
有两个变体,SIM-Hard
和 SIM-Soft
。
SIM-Hard
是一个固定的搜索函数,它使用 category id
等单一特征从用户行为序列中进行搜索,这不够灵活,并且可能导致 retrieved behaviors
不是最优的。
SIM-Soft
使用局部敏感哈希 (local-sensitive hashing : LSH
)进行 MIPS
从而找到相对于 target item embedding
最邻近的 item embedding
。item embedding
使用辅助损失进行训练。
SIM-Soft
的第一个缺点是它依赖于辅助任务,如果 user behaviors
太多,则需要随机采样。
第二个缺点是LSH
使用的索引应该经常更新(但是实际上没有更新),因为 item embedding
在训练时会发生变化。
最后,ranking
函数仅限于内积形式,缺乏建模能力。
ETA
使用 SimHash
生成 item embeddings
的二进制指纹,并计算 target item
指纹与 behaviors
指纹之间的汉明距离
STARec
利用 item embeddings
之间的余弦相似度作为 ranking
函数。
因此,所有现有的 retrieval-based
的模型都遵循预定义的函数来检索 behaviors
,因此缺乏灵活性和学习能力。
基于本文中描述的 matching
和 ranking
,我们在 Table 2
中总结了现有模型。SIM-Hard
本质上使用预定义的特征来匹配 user behaviors
,而 SIM-Soft
直接使用 MIPS
对 behaviors
进行排序,而无需matching
过程。 ETA
和 STARec
也在 Table 2
中进行了总结。
总体而言,UBR
的检索机制与其他模型的比较如 Figure 6
所示。
对于 UBR
,matching
子模块在很大程度上减少了 user behavior set
的大小。由于这个 reducing
过程本质上是访问 selected features
的倒排索引,因此可以非常快速地进行,效率很高。设计这样的 matching
过程最重要的原因是避免对整个用户历史序列
相反,其他 one-stage retrieval models
选择对整个序列进行计算。为了快速地进行计算,它们实现尽可能简单的检索函数,例如汉明距离(ETA
) 或余弦相似度 (STARec
)。因此,这些模型的检索函数都是非参数化的,并且基于某种预定义形式。尽管非参数化的检索函数的输入可以是 learnable embeddings
,但函数的预定义形式限制了建模能力。因此,具有任意参数的可学习的检索函数是我们文章的主要关注点。
此外,我们将检索函数实现为一个两阶段过程,以平衡有效性和效率。更多实验证据可在实验章节中找到。
至于 UBR
的不同变体:
UBR-M
是由我们的会议文章(《User behavior retrieval for click-through rate prediction》
)提出的,它使用 selected features
来匹配相应的 user behaviors
。feature selection
由 REINFORCE
算法优化。但它仍然使用固定的 ranking
函数。
UBR-R
是一种新模型,它使用所有特征来匹配 behaviors
,从而产生比UBR-M
更大的 candidate behavior set
。我们提出了一个参数化的 ranking
函数,它可以是任意结构,我们使用 LTR
对其进行优化。由于LTR
过程有效地训练了 ranking
函数,UBR-R
可以使用所有特征来匹配 candidate set
并准确获得 top-k behaviors
。
UBR-MR
是上述变体的混合版本,同时优化了 matching
子模块和 ranking
子模块。虽然 UBR-MR
同时优化了两个子模块并可以获得更好的性能,但它并不总是最好的选择。
第一个原因是它的复杂性。在训练中,两个子模块都进行了优化,并且消耗的时间比 UBR-M
或 UBR-R
大得多。
第二个原因是,如果数据集只有非常有限的特征(例如,item features
只有 item id
以及 category id
),那么在 matching
中选择特征并不总是一个好主意。在这种情况下,使用所有特征来匹配 behaviors
是更好的选择。
实验章节中介绍了更多相应的结果,以及选择更好变体的见解。
本节将介绍大量实验的细节。我们将我们的模型与几个强大的 baselines
进行了比较,我们的模型在离线和在线评估中都取得了 SOTA
的性能。实现代码已发布(https://github.com/qinjr/UBR4CTR
)。
数据集:我们使用三个真实的、大型的 users online behaviors
数据集。数据集的统计数据可以在 Table 3
中找到。
Tmall
数据集:由阿里巴巴集团提供,其中包含 2015
年5
月至2015
年11
月天猫电商平台上的user behavior
历史记录。
Taobao
数据集:包含来自淘宝中检索到的user behavior
数据。它包含 2017
年 11
月25
日至 12
月3
日的user behaviors
,包括点击、购买、添加到购物车、以及喜欢商品等几种behavior
类型。
Alipay
数据集:由支付宝收集。用户的在线购物behaviors
是从 2015
年7
月1
日到2015
年 11
月 30
日。
数据集预处理:对于 UBR
,数据集被处理成逗号分隔特征的格式。包含 user, item and context features
的一行被视为一个 behavior
。对于 baselines
,user behaviors
仅按时间戳排序。由于这三个数据集仅包含点击样本(即正样本),我们按照 《Deep interest evolution network for click-through rate prediction》
、《Deep interest network for click-through rate prediction》
中的处理协议进行 1:1
负采样。
Basic Retrieval Engine
:我们使用逗号分隔的 tokenizer
将数据集插入一个 retrieval engine
。我们使用ElasticSearch
作为 backbone retrieval engine client
,从而对公共数据集进行离线实验。Tmall
、Taobao
、以及 Alipay
数据集的 posting list
平均长度分别为 6.9
、7.3
和 8.9
。
训练集和测试集的拆分:我们使用 leave-one-out
策略(按时间顺序排序)来拆分数据集。
训练集包含第 user behaviors
,其中第 behaviors
用于预测第 behavior
。
类似地,验证集使用第 behaviors
来预测第 behavior
。
测试集使用第 behaviors
来预测第 behavior
。
评估指标:AUC
、Logloss
(简写为 LL
)。
baselines
:我们将 UBR
与一些强基线进行比较,这些 baseline
来自 user behavior-based
的 CTR
模型、以及序列推荐模型。
DeepFM
是一种混合模型,以双塔方式结合了 FM
和深度神经网络。
PNN
是一种单塔模型,在深度网络中结合了基于内积的特征交互。
DCN
使用多层交叉网络来建模特征交互。
GRU4Rec
基于 GRU
,这是第一篇使用 recurrent cells
来建模 sequential user behaviors
从而用于 session-based recommendation
的工作。
Caser
是一种 CNNs-based
的模型,它将用户序列视为图像,因此使用水平的和垂直的卷积层来捕获 user behaviors
的时间模式。
SASRec
使用 Transformer
。它将 user behaviors
视为 tokens
的一个序列,并使用自注意力机制和 position embedding
来捕获 behaviors
之间的依赖关系和关联。
HPMN
是一种分层周期性记忆网络(hierarchical periodic memory network
),旨在处理非常长的用户历史序列。此外, user memory state
可以增量地更新。
MIMN
基于神经图灵机(Neural Turing Machine
),可对建模用户兴趣漂移的 multiple channels
。该模型是作为 ser interest center
的一部分来实现的,可以建模非常长的用户行为序列。
DIN
是第一个在在线广告的 CTR prediction
中使用注意力机制的模型。
DIEN
使用带有注意力机制的两层 RNN
来捕捉不断演变的用户兴趣。它使用计算出的 attention values
来控制第二个 recurrent layer
,称为 AUGRU
。
R-Att
使用
Reformer
是针对 Transformer
结构提出的,可以有效地处理长序列。它使用 LSH
来降低自注意力的计算复杂度。
SIM
是 retrieve-based
的模型,其动机与 UBR
相似。SIM
有两种变体:SIM-Hard
和 SIM-Soft
,分别利用确定性的 hard search
、以及 embedding-based MIPS
。
ETA
利用 SimHash
算法生成 target item
的二进制指纹、以及 historical items
的二进制指纹。它使用汉明距离来获取 top-k nearest behaviors
从而作为 retrieved behaviors
。
STARec
直接根据 target item
的 embedding
和 behaviors embeddings
来计算余弦相似度。然后它检索与 target item
最相似的 behaviors
。
在本节中,我们对 UBR
进行了详细的实验,包括整体性能比较、消融研究和超参数研究。此外,还介绍了 UBR
的训练过程的比较、以及推理时间比较。
我们对基线进行了两组实验。
第一组:由于传统的 user behavior modeling
利用最近的连续行为,我们将最近的 behaviors
馈入基线。20%
。
第二组:整个用户序列被馈入到基线模型中。
为了公平比较,UBR
将从整个用户序列中检索 behaviors
。基线使用不同的网络结构来学习 user behaviors
的 unified representation
,而 UBR
聚合 retrieved behaviors
。不同模型计算出的 representation of user behaviors
和其它特征一起被馈入到 DNN
。我们对不同的模型使用相同的 DNN
结构,唯一的区别是模型如何利用用户行为数据。
结果如 Table 4
所示。从表中我们发现以下事实:
(i)
:UBR
(UBR-R/UBR-MR
)取得了最佳性能。在三个数据集上,它的 AUC
比最佳基线模型分别高出 5.1%
、2.1%
和0.9%
。在三个数据集上,Logloss
分别改善了 11.2%
、0.2%
和 3.8%
。结果证明了 UBR
的有效性。
(ii)
:通过比较 retrieved-based
的模型和传统模型(recent k behaviors
),观察到显著的改进,这表明直接检索 user behaviors
的重要性。
使用 recent k behaviors
的传统模型表现不佳。这表明最近的连续行为序列可能没有包含足够的时间模式。因此,模型无法有效地捕获 patterns
。虽然基线模型使用了复杂的网络结构,但由于输入数据的原因,它们无法获得良好的性能。
(iii)
:对于使用全长序列的传统基线,我们可以发现大多数基线模型的性能都有所提高,表明较长的序列携带着更丰富的信息和模式。
然而,UBR
仍然优于传统基线。这表明较长的序列可能包含更多的噪音和不相关信息,因此有必要从整个序列中只获取最相关的信息。
(iv)
:UBR-R
和 UBR-MR
优于现有的 retrieval-based
的模型和 UBR-M
。这验证了我们新提出的参数化的 ranking
函数和相应的 LTR training
的优越性。
为了增加测试难度并进一步验证 UBR
的有效性,我们通过按用户而不是时间来拆分 Tmall
数据集,并进行了额外的实验。我们从 non-retrieval models
中选择了 DIN
和 DIEN
,因为它们在 Tmall
数据集上表现良好,并列出了所有 retrieval-based
的基线。我们根据用户来拆分,训练集、验证集、测试集分别包含 80%
的用户及其对应的用户行为序列。结果如 Table 5
所示。
Retrieval
模块的重要性:为了验证 retrieval
模块的必要性,我们使用最近 k behaviors
而不是 retrieval
模块,然后使用不同的聚合函数。结果如 Table 6
所示。我们测试了两种不同的 behavior
聚合函数:sum pooling: SP
和 attention: ATT
。
从表中我们发现:
配备 UBR
模块后,两种聚合函数的预测性能都得到了很大程度的提高。结果证明了 retrieval
模块的重要性。
此外,我们可以发现,即使采用像 sum pooling
一样简单的聚合函数,SP w\ UBR-R
也可以实现与 ATT
相比具有竞争力的性能。这一事实证明了 retrieved behavior data
的有效性。
此外,UBR-R
可以带来比 UBR-M
更多的性能提升,这验证了我们提出的 ranking
函数和 LTR training
的有效性。
不同 UBR
变体之间的比较:为了弄清 retrieval
模块的不同子过程的影响,我们在 UBR-Fix
(固定的 retrieval system
)、UBR-M
、UBR-R
(使用两种不同的 ranking losses
:BPR loss
(《BPR: Bayesian Personalized Ranking from Implicit Feedback》
)、lambdaloss
)以及 UBR-MR
之间进行了另一次消融实验。
结果如 Table 7
所示。我们有以下观察和分析:
(i)
:UBR-Fix
在大多数情况下表现不如 UBR
的三个可学习的变体,这表明有必要使 retrieval system
可学习。
(ii)
:在这三个数据集中,UBR-R (Lambda)
优于 UBR-R (BPR)
。这表明在 ranker
的性能。
(iii)
:UBR-MR
在 Tmall
和 Alipay
数据集上优于 UBR-R
和 UBR-M
,但在 Taobao
数据集上表现较差。此外,在 Taobao
数据集上,UBR-Fix
优于 UBR-M
。
UBR-M
和 UBR-MR
的共同点在于它们都使用 selected features
作为 query
来进行 matching
过程。但是, Taobao
数据集只有两个 item features
(item id, category id
)。如果 selector
为某些样本删除一个特征(例如 category id
),则许多有用的 behaviors
将被删除,并且没有机会进行排名。相反,Tmall
和 Alipay
数据集有四个 item features
(item id, category id, merchant id, and brand id
),这为 feature selector
提供了更大的操作空间。因此,matching
过程可以得到更充分的训练,并产生更好的性能。
至于 UBR-Fix/UBR-R
,它们从更大 candidate set
(从所有可能得特征中获取)中对 behaviors
进行排名,因此它们在 Taobao
数据集上取得了更好的性能。
(iv)
:我们进一步介绍了每个 UBR
变体的训练时间。
UBR-Fix
无疑是最快的,因为它使用了不可训练的 retrieval
模块。
UBR-MR
的训练时间大约是 UBR-R
的 2-3
倍,因为两个子模块都经过了优化。因此,UBR-MR
的收敛速度要慢得多。
在大多数情况下,考虑到 UBR-R
在训练效率和测试性能之间的良好平衡,它已经足够好了。特别是当数据集的特征很少时, learning to match
不是一个好主意(例如 Taobao
数据集)。总而言之,UBR-R
是一个足够好的做法;而 UBR-MR
是一个更难的版本,可以实现更好的性能,但它需要更多的成本训练并增加整个系统的复杂性。
本节我们研究了 retrieval size k
的影响。Figure 7
展示了 UBR-M
、UBR-R
和 UBR-MR
在不同 retrieval size k
下的性能。从图中可以看出,AUC
和 logloss
的波动在绝对值上并不是很剧烈。然而,每个数据集都存在一个最优规模。这表明较小的 behaviors
和信息;而太多的 retrieved behaviors
并不总是对性能有益,因为它们会包含更多的噪音。
本节我们展示了 UBR
框架的训练过程。我们以 UBR-R
为例。prediction
模块的性能曲线如 Figure 8
所示。在曲线中,我们绘制了不同 test points
的 test AUC
值。图中,“P”
对应于 prediction
模块的训练过程(蓝色阴影区域),而 “R”
代表 retrieval
模块的训练(粉色阴影区域)。
我们在训练数据集每间隔迭代 20%
后测试一次 CTR estimation
的性能。因此,对于 prediction module training
的一个 epoch
,我们可以有五个 test points
。
当训练好 retrieval
模块时,我们每个 training epoch
测试一次 prediction
模块。
从图中可以看出:
在第一个粉色区域( retrieval
模块正在训练)中, prediction
模块的测试性能显著提高。在粉色区域中,prediction
模块是固定的,因为两个模块是轮流训练的。
在第一个粉色区域之后,prediction
模块接近收敛。接下来的训练逐渐提高性能,直到最终收敛。
test AUC
曲线验证了 UBR
的训练策略,retrieval
模块实际上学习了有意义的模式,因为它可以在训练期间检索更多有用的 behaviors
(test AUC
正在提高表明了这一点)。
为了解决效率问题,我们比较了UBR
和其他 user behavior-based
的CTR
模型的推理时间。Figure 9
显示了模型的平均推理时间。该时间是通过将测试数据集上的总时间除以 batches
数量来计算的。仅包括包含前向计算和 behavior retrieval
的时间。我们在具有 Intel(R) Core(TM) i7-6900K CPU
处理器、一块 NVIDIA GeForce GTX 1080Ti GPU
处理器和 128 GB
内存的机器上实现了两个版本的 index storage
。一种索引基于Elastic Search
,并持久保存在磁盘上;而另一个版本则将索引结构加载并存储在内存中。
UBR-M
、UBR-R
和 UBR-MR
具有相似的推理时间,因此我们使用 UBR
作为统一的名称。因为主要开销来自 retrieval
过程。 如图所示,UBR (in disk)
的推理时间最长。但是,在这三个数据集上,每个样本的推理时间不超过 1ms
,这表明合并 retrieval
模块不会严重损害效率。
由于公共数据集的索引结构可以存储在内存中,我们实现了内存存储版本的 UBR
并测试了它的推理时间。我们发现更快的存储将显著提高 retrieval
模块的效率,并验证了 UBR
的主要开销来自访问磁盘。 倒排索引所消耗的内存存储如 Table 8
所示。
总体而言,UBR
会带来一些效率问题和内存开销,但并非无法忍受。我们接下来的在线实验进一步验证了这一点。
在本节中,我们从有效性和复杂度方面比较了 UBR-MR
和 one-stage retrieval models
。我们在 Table 9
中列出了test AUC
、训练时间、以及推理时间。T-Inf
是模型完成一个 batch
测试样本的计算的 wall time
。
从表中我们可以看出:
UBR
的性能最好,但其训练时间明显超过基线,这表明没有免费的午餐。
UBR
的推理复杂度为 matching
过程给出的 candidate behaviors
的数量);而其他模型的复杂度为 UBR
的 matching
操作需要额外的开销
综上所述,结果表明,与其他 one-stage retrieval models
相比,UBR
具有更好的效果,以及具有竞争性的推理效率。
我们在 Tmall
数据集中选取了 behaviors
超过 1,000
个的用户,从而对非常长的序列进行了广泛的实验。选定的用户数量为 2,900
。我们为每个用户使用一个 positive item
和九个随机采样的 negative items
,形成一个名为 Tmall-Long
的数据集。这个数据集用于推理过程。本次实验在具有 12 GB GPU
内存的 NVIDIA 1080 Ti
卡上进行。我们在这个数据集上测试了 UBR
与其他 attention-based models
的性能和开销。
结果如 Table 10
所示。从表中可以看出:
UBR-MR
明显优于 attention-based
的模型。这表明,对于非常长的序列,UBR
表现出比注意力机制更好的建模能力。因为在 1,000 behaviors
中,可能会有很多噪音,而 retrieval
模块可以直接关注最相关的行为。
就开销而言,DIN
是最快的模型,但 UBR-MR
在速度上仍然优于 DIEN
。这种推理效率是可以接受的。
至于 GPU
内存消耗,UBR-MR
是最好的,因为只有 matching
子模块给出的 candidate behaviors
才会放入 GPU
内存中,我们将 candidate behaviors size
设置为 100
。这意味着不会有超过 100 behaviors
被馈入到 ranking
子模块。
SASRec
占用了太多内存,超过了 GPU
的内存大小。
这个实验展示了从很长的序列中 retrieving behaviors
(而不是直接将整个用户序列馈入到 attention model
)的优势。如果序列长度增长到 10,000
的级别(如 《Search-based user interest modeling with lifelong sequential behavior data for click-through rate prediction》
所示),由于计算和 GPU
内存的负担很重,attention
无法直接使用。但是 retrieval
模块可以处理它,因为我们总是可以获取一小部分 behaviors
,并仅将这一小部分 behaviors
提供给 prediction
模型。
UBR
已在真实世界部署中进行了测试,并取得了可喜的成果。在本节中,我们展示了在 Huawei App Store
付费广告场景中获得的离线和在线评估结果。app store
每天有数亿活跃用户,每天会产生数百亿个用户日志事件,这些事件包括浏览、点击和下载 apps
等隐式反馈。
设置:离线评估是在工业数据集上进行的。工业数据集由 Huawei App Store
上主页广告场景的八天日志组成。前七天的日志用于训练,第八天的日志用于测试。对于工业数据集,positive ratio
约为 0.3%
。UBR
从用户过去一年的 behaviors
中检索数据,这意味着每个用户的 retrieval pool
都包含该用户去年的所有 behaviors
。
我们通过将 retrieved behaviors
(聚合后)作为新特征添加到 base model
来测试 UBR
性能。此 UBR
特征与其他常规特征拼接在一起,并馈入到 CTR
模型。base
模型是 DCN
、DeepFM
和 PNN
,因为它们是广泛使用的工业级 CTR estimation
模型。
结果:结果如 Table 11
所示。
对于三个不同的 base models
,UBR-M
带来了 0.95%
、0.93%
和 1.17%
的 AUC
改进。
与 base model
相比,UBR-R
将 AUC
指标提高了 1.10%
、1.09%
和 1.38%
。结果验证了 UBR
可以与其他模型一起使用,并实现显著的性能提升。
从表中,我们还观察到 UBR-R
可以比 UBR-M
带来更多的性能提升,这表明 ranking function
是 UBR
系统的重要组成部分。
至于 UBR
的开销,每个 batch
的推理时间增加了 31%
,但仍少于 100
毫秒。由于倒排索引结构在内存中被存储,内存消耗增加了 56%
。这个成本对于工业级应用来说是可以接受的。
设置:我们在 Huawei App Store
的付费广告场景中进行 A/B test
。部署的场景位于 Huawei App Store
的主页上,它是 App Store
的主要广告服务。商业的 baseline
表示为 UBR-enhanced model
表示为 UBR
(具体而言是 UBR-R
)从过去一年检索到的 user behaviors
。在 A/B Test
实验持续 24
天,分为两个阶段:
第一阶段随机选取总用户数的 20%
,其中一半作为实验组,另一半作为对照组。
第二阶段随机选取 50%
的用户进行 A/B Test
。
两个阶段都持续 12
天。每个阶段,我们进行 5
天的 A/A test
,然后进行 7
天的 A/B test
。在 A/A test
期间,所有用户都由base model
A/B test
期间,对照组用户使用base model
apps
,而实验组用户使用 apps
。我们使用 Redis
存储 user behaviors
的倒排索引结构。
我们使用一台配备 48 core Intel Xeon CPU E5-2670 (2.30 GHz)
、400 GB RAM
、以及2张 NVIDIA TESLA V100 GPU
卡的机器来部署 UBR
。在压力测试中, 30%
。
指标:我们检查了 online evaluation
中广泛采用的两个指标:
有效的每千次展示费用(effective Cost per Mille: eCPM
):
点击率(Click-Through Rate: CTR
):
其中:num of downloads
和 num of impressions
分别是下载次数和展示次数。
结果:eCPM
和 CTR
的改进分别如 Figure 10
和 Figure 11
所示。可以看到,系统非常稳定:
在 A/A test
期间,eCPM
和 CTR
在 1.5%
以内波动。
在第 6
天到第 12
天和第 18
天到第 24
天,A/B test
期间,当
在 20%
流量 A/B test
中,eCPM
和 CTR
的平均提升分别为 4.5%
和 6.6%
。
对于 50%
流量的 A/B test
,eCPM
和 CTR
平均分别提高了 6.6%
和 11.1%
。
这些结果清楚地证明了UBR
的优越性,目前它已全面部署在 Huawei App Store
的付费广告场景中,并服务于所有流量。