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函数）
定义为”Ui排在Uj前面”这个论述的真实性(ground truth)，1代表论述为真，0代表为假，0.5代表Ui与Uj位置应该相同。如下图所示，做一个简单的数据变换，用
来代表“Ui排在Uj前面”论述的真实性。从而我们可以定义binary cross entropy loss如下
我们再简化一下“训练集”的构成，因为如果一对儿文章“Ui排在Uj前”为真，那么”Uj排在Ui前”一定为假，导致冗余。所以，在训练集中，我们只需要保留所有 =1的训练样本。然后再让以上binary cross-entropy loss对”待优化变量
”求导，则有
注意上式中，“预测得分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中一样
- 将Ui,Uj的位置调换，计算NDCG的变化
，然后将
以上公式中，在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中
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领域的地位还任重道远。