最新消息:非无江海志,潇洒送日月

Google TensorFlow下的TF-Ranking的源代码以及流程分析

科学研究 江海志 8773浏览 0评论

Google最近开源了基于TensorFlow的Learning-To-Rank(LTR)框架TF-Ranking。最初我很是兴奋。这是因为

  • LTR比目前常用的预测点击/转化的二分类算法,更加符合推荐系统的实际需求
  • 我经常使用lightgbm, xgboost来进行LTR,但是GBDT天生只擅长处理稠密特征,而“稀疏特征”才是推荐、搜索领域中的“一等公民”。TF-Ranking基于TensorFlow,可以充分利用embedding, crossing, hashing等手段来处理“稀疏特征”。
  • TF-Ranking是一个框架,可以接入任意一种算法来计算query-doc, user-item之间的相关性,也可以在pointwise/pairwise/listwise这三大类loss function中方便切换。这使我们可以轻松尝试多种组合,比如基于wide&deep的pairwise LTR,基于deepfm的listwise LTR。
  • TF-Ranking是基于TensorFlow Estimator框架实现的,自动具备了分布式训练、部署的能力,可以应对海量数据集。

所以,我马上下载了TF-Ranking的源码来阅读,但是粗读一遍之后,却有些失望

  • 众所周知,TensorFlow的运行方式是“先定义DAG,再执行”。但是,一个机器学习算法,并不全是矩阵运算与求导。排序、组织pair之类操作,用普通python代码很容易完成,在tensorflow中非要调用蹩脚、文档不健全的api来完成。Tensorflow与其说是一个python库,不如说是一门全新的语言,而且这门语言细节繁杂(光“回”字就有4种写法)且缺少文档。
  • TF-Ranking因为一些“华而不实”的功能而复杂了代码,比如所谓的Groupwise Scoring Function功能;但对一些实际工程上极其重要的功能,比如“稀疏化”却支持得不够好。

总之,如果下次我要训练一个LTR模型,我肯定还首选LightGBM来完成。不过,我还是将一些重要的代码细节总结如下,可以从中管窥LTR算法的实现,也可以学习一些TensorFlow的高级用法。


LTR简介

在正式介绍TF-Ranking之前,还是需要简单介绍一下LTR算法本身。

目前广泛使用的一些推荐算法,本质上还是二分类算法,类似于“点击率预估”。尽管线上效果还不错,但是距推荐系统的实际需求还有差距:

  • 推荐系统中的“排序”任务关心的是相对顺序正确与否,而不是对“单个物料的点击概率”预测得是否精准。
  • 二分类优化的loss只基于“预测分数”与“真实值”的差异,对“预测分数”可导,可用Gradient Descent优化之。而推荐系统中的很多业务指标,如NDCG, MAP,是基于“排序位置”的。“预测分数”的微小变化,或者不足以改变顺序使metric不变,导数始终为0,或者改变排序而导致metric剧烈变化,不可导,使得无法用Gradient Descent优化。

为此,Learning-To-Rank算法应运而生。学习LTR,经典的教材是Microsoft的《From RankNet to LambdaRank to LambdaMART: An Overview》一文。我将其中的原理简述如下。

用户输入一个query q,待排序的两篇文章Ui, Uj, si是模型给文章Ui打的分数,预测q与Ui的相关性,sj是模型给Uj打的分数,预测q与Uj的相关性。我们可以预测将Ui排在Uj前的概率,从而将排序转化成一个二分类问题, “Ui排在Uj前面”的概率定义如下(注意 [公式] 是一个超参,不代表sigmoid函数)

图1. 文章Ui排在Uj前的概率是si-sj的sigmoid函数

[公式] 定义为”Ui排在Uj前面”这个论述的真实性(ground truth),1代表论述为真,0代表为假,0.5代表Ui与Uj位置应该相同。如下图所示,做一个简单的数据变换,用 [公式] 来代表“Ui排在Uj前面”论述的真实性。从而我们可以定义binary cross entropy loss如下

图2

我们再简化一下“训练集”的构成,因为如果一对儿文章“Ui排在Uj前”为真,那么”Uj排在Ui前”一定为假,导致冗余。所以,在训练集中,我们只需要保留所有 [公式] =1的训练样本。然后再让以上binary cross-entropy loss对”待优化变量 [公式] ”求导,则有

图3

注意上式中,“预测得分s对w”的导数[公式][公式],可以由NN来实现,也可以由GBDT来实现,属于“开箱即用”的成熟技术,就不用赘言了。在这里,我们关心的是[公式],即loss function对第i篇文章的预测得分的导数,注意这里我们用 [公式] 来表示,这也就是LambdaRank, LambdaMART一系列算法名字的由来。

注意两点,

  • 这里的[公式]还是一个真的梯度,区别于下面要说的为了优化某不可导指标而人为设计的梯度
  • 以上binary loss function,对“列表头部的排序正确性”与“列表尾部的排序正确性”一视同仁,实际上优化的是AUC

而如果我们要优化NDCG这样重点关注头部位置的指标,正如前所述,这些指标对单个文档的“预测得分”的微小变化,要么无动于衷,要么反应剧烈,即我们无法定义一个“既能优化NDCG,又对 [公式] 连续可导”的loss。那怎么办?

LambdaRank/LambdaMART的解决思路,简单而被证明有效:既然无法定义一个符合要求的loss,那就不定义了,直接定义一个符合我们要求的梯度就行了。这个不经过loss,而被人为定义出来的梯度,就是所谓的Lambda梯度

那么优化NDCG需要怎样的Lambda梯度?很简单,

  • 在上一轮迭代结束后,将候选文档/物料,按照上一轮迭代得到的预测分数从大到小排序
  • 对<Ui,Uj>这一对儿,如果还用binary cross entropy loss预测排序是否正确,其梯度定义和图3中一样
图4. 不考虑优化指标,只考虑排序正确性时的Lambda梯度
  • 将Ui,Uj的位置调换,计算NDCG的变化 [公式] ,然后将[公式]乘到上一步得到的Lambda梯度上,就是优化NDCG所需要的Lambda梯度

以上公式中[公式],在TF-RANKING的代码中被称为Lambda weight。优化不同的指标,将会定义不同的Lambda weight。

综上所述,我们可以看到,实现一个Learning-To-Rank算法,有4个重点:

  • 样本如何组织。显而易见,排序只对“同一个query下的候选文档”或“同一个推荐session下的候选商品”才有意义。所以,与普通二分类不同,LTR训练集有一个分组的概念,同一个组内的候选物料才能匹配成对,相互比较
  • 打分。本来很简单的一个步骤,将query-doc, user-item的特征喂进模型,模型的输出就是我们需要的分数,预测query-doc, user-item的相关程度。但是TF-Ranking却使用了所谓的Groupwise Scoring Function(GSF),给一个候选物料 [公式] 打分时,要把它与其他候选物料编组,并且要考虑[公式]在组内的不同位置上,然后给这一组同时打分。我觉得是一个华而不实、得不偿失的功能。
  • 定义loss。Learning-To-Rank有pointwise/pairwise/listwise三种定义loss的方式。Pointwise与普通的ctr预估无异,上面的例子介绍的就是pairwise, listwise以后找个机会再介绍。不同的loss定义方式,再结合优化不同指标而定义的不同lambda weight,可以衍化出更多种算法。
  • Lambda Weight。如前所述,根据需要优化的指标(NDCG/MAP/MRR)的不同,需要定义不同的lambda weight,乘在 [公式] 的前面

接下来,就让我们看看,TF-Ranking是如何实现以上四个方面的。


加载数据

排序必须针对同一个query,或同一个推荐session。所以,一个样本必须是针对同一个query,或隶属同一个推荐session的候选item/doc list。这一点在data.libsvm_generator这个函数中有所体现,它把具有相同qid的样本聚合在一起。从libsvm文件中加载数据的代码如下所示:

这里op_next_features是一个dict,key是feature name,value是[batch_size, list_size, 1]形状的tensor。List_size就是一个query下待排序的最大doc/item数目。如果不足,要补齐;如果超过,则要抽样截断。这种固定list_size的做法,既浪费空间,又复杂了代码,使得代码充斥着对相应位置的x或y是“真实元素”还是“填充元素”的判断。

尽管TF-Ranking声称自己是scalable的,但是仅从目前的数据加载上来看,每个特征都读成[batch_size, list_size, 1]的稠密矩阵。而在实际系统中,这样的矩阵肯定有不少超级稀疏的,甚至是全0的,从而浪费了大量内存与计算时间。


打分

打分遵循了Learning Groupwise Scoring Functions Using Deep Neural Networks这篇文章的思路,是所谓的multi-item scoring,即同时给一组候选物料同时打分。之所以这样做,根据作者的说法,是为了模仿用户在面对物料列表时先相互比较,再决定点击哪一个的“比较”过程,因此给某物料打分必须要考虑该物料所在的group。

做法上也很简单、粗暴,一个group_size=m的group,就是将m个物料的特征都拼接起来,喂入模型。而NN的最后一层也不再只有一个输出,而必须输出m个数值,即同时为组内的所有物料打分。拼接就会有顺序问题,为使预测结果不受拼接顺序的影响,就必须考虑从全部n个候选物料中抽取一个长度为m的group的所有排列组合。当然论文中也提出了简化算法,即先shuffle再依次取长度为m的滑窗。

tf_ranking_libsvm._score_fn中,提供了一个打分函数的例子

以上User-defined scoring function只是针对从全部n个候选文档中抽取出来的单一一个group的。从全部n个候选文档中多轮抽取m个文档,再聚合多轮得分的过程发生在model.make_groupwise_ranking_fn._groupwise_dnn_v2这个函数中

我对这种所谓的Groupwise/Multi-Item Scoring很不以为然。模仿用户在物料序列中的“先比较、再选择”的行为,已经由Pairwise/Listwise Loss Function体现了,在打分上再体现“比较”的意味,最多算是锦上添花。但是付出的代价,却是

  • 按组拼接特征导致的特征维度增长,
  • 考虑多种拼接顺序导致的训练/预测样本的增加,
  • shuffle导致的训练与预测时的不确定性,

总之,我觉得“得不偿失”。所以在自带的例子中,group_size的缺省值就是1,又切回了传统的所谓single-item scoring的模式。


Loss Function

以经典的pairwise_logistic_loss为例,它的定义在losses._pairwise_logistic_loss

_pairwise_loss


Lambda Weight

LTR的一大优点就是能够直接优化NDCG, MAP这样依赖排序、不可导的指标。其作法是在计算普通的pair loss之后,为每个pair loss乘以一个权重,即代码中的lambda weight。比如在按照上一轮迭代后所有文档的得分排好序后,某两个文档 [公式][公式] ,调换二者顺序而导致的NDCG的变化,就是<[公式],[公式]>这一对儿的lambda weight。

Lambda weight计算器的基类_LambdaWeight和优化不同指标的lambda weight的实现都定义在losses.py中。以最常见的优化NDCG为例,具体实现见losses.create_ndcg_lambda_weight函数,

而真正计算lambda weight发生在DCGLambdaWeight.pair_weights函数中


总结

本文记录了TF-Ranking源代码中一些重要的代码片段,能够提纲挈领地串起整个TF-Ranking的代码流程。在我看来,TF-Ranking现阶段还不成熟,加入Grouping Scoring Function这样华而不实的功能使代码变得复杂,却对“稀疏”这样的实用功能支持得不够好。尽管Google声称使用TF-Ranking在Gmail Search和Google Drive Recommendation上都发挥出很好的性能,但我觉得,目前的TF-Ranking离撼动RankLib, LightGBM在LTR领域的地位还任重道远。

转载请注明:江海志の博客 » Google TensorFlow下的TF-Ranking的源代码以及流程分析

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址