02 4.00
同一个用户面对同一页推荐,这次可能刷到第 20 条点了两件,下次刷到第 8 条就走了;日志只记下其中一次。BrowseFlow 认为用户模拟器该学的是这种结果的分布,而不是复刻那一条日志。它把一次浏览拆成两件事:刷到多深,以及在哪几个位置点击或点赞,直接生成这几个关键事件,而不是一步步预测大量的下滑动作。这一点很重要,因为在淘宝的浏览数据里只有 5.48% 的动作是点击这类正反馈。在三个数据集上,它生成的浏览结果整体分布和点击次数分布都最接近真实。
03 3.80
很多应用的推荐模型由外部服务商托管,运营方只能调接口拿分数,改不了模型参数。这时用户要求删掉一条误点或过时的行为,现有的推荐遗忘方法都用不上,因为它们要重训或微调模型。CEU 不改模型,只改输出。模型托管方事先算好每条历史行为对每个推荐结果的贡献,也就是去掉这条行为后该物品的分数会少多少,经接口一起提供。运营方收到删除请求后,把受影响物品的分数扣掉这部分贡献再重排。在三个公开数据集上,它的遗忘效果与完全重训相当。处理一次删除请求最慢也只要 6.37 秒,完全重训则要几分钟到一个多小时。
04 3.65
一个推荐系统如果完全不看用户属于哪个群体,只按全体用户的平均口味推荐,少数群体会一直吃亏。作者证明,只要全体最爱的那组物品对某个群体不是最好的,这种策略相对每个群体最优推荐的累积差距就会随时间线性增长。难点在于群体会交叉,一个人可以同时属于好几个群体。作者给了两条路:给每个交叉组合单独学偏好,有理论保证,但组合一多每组数据就不够;或者先按大群体学,再由一个选择器根据过去的反馈,决定每个交叉组合此刻沿用它所属哪个群体的推荐。在两个数据集上,组合口味和大群体接近时第二条路更好,差别大时第一条路更好。
05 3.45
地点推荐会改变人们去哪儿吃饭,平台又拿这些被引导出来的到店记录重新训练,形成一个闭环。离线准确率测不出这个闭环的长期影响,作者就用美国四个都市圈的真实出行数据做了长期模拟,并考虑了路程远近和店面容量。结果是,不论用哪种算法、在哪个城市,至少五分之一的餐饮店最后没人去,其中一大半是反复重训造成的。论文用收入隔离来衡量相遇:一个人在店里遇到的人,收入构成越偏向某一档,隔离越重。越准的算法隔离越重,最准的算法比居民真实出行高出 15% 到 21%。在现有推荐之上给冷门店加权重排,两个问题都能缓解。
06 3.75
推荐模型训练时,前半段要处理几千个特征字段和万亿级 embedding 表,操作又碎又随机;后半段是越来越大的 Transformer,算得又密又整。两段放在同一批 GPU 上,GPU 常常在等数据。阿里的 RecIS 把从原始特征到稠密计算的整条路径当成一个整体来优化:把零碎的特征处理合并成大算子,按哈希把 embedding 查询均匀分到各卡并去掉重复传输,再让下几步的输入准备和当前一步的稠密计算同时进行。在工业推荐模型上,吞吐最高是 TorchRec 的 1.15 倍、PICASSO 的 2.62 倍。
07 3.45
新上线的题库平台有题目文本,却还没有可以拿来训练的答题记录,能不能直接用别的平台训练的模型预测学生下一题答对答错?把题目文本的语义当特征直接搬过去效果有限,因为各平台出题风格差别很大。TIZSKT 只把文本当作找相似题的索引。模型本身只学答题对错的变化规律,不看题号和文本。预测时,学生刚在新平台做过的题和对错是已知的:先用文本挑出和当前题相似的,汇总他在这些题上的对错,再和模型学到的答题状态合起来算答对概率。新平台不用训练,在三个公开数据集上平均 AUC 最高。
08 3.05
推荐系统要同时照顾用户、内容创作者、平台,还有开发者、监管方乃至整个社会,每一方又有好几个目标。多方多目标推荐已经有不少研究,但很少有人问这样的系统值不值得信任。这篇立场论文认为,可信不只是少出偏见和隐私问题,还要主动照顾人的价值,并处理各方目标之间的冲突。它举的例子是:创作者推广健康饮食视频本身没问题,推给有进食障碍的用户却可能伤害对方。论文没有新方法或实验,列出了四个待解决的问题:多目标下对谁公平、怎么把人的价值变成可衡量的目标、目标变多带来的计算开销,以及欧盟法规要求平台解释推荐依据。