Intern Experience @Kwai
Timeline @Kwai:
在 2020-9-2 日，我正式和组内 leader、部门 leader 以及 hrbp 提出了离职申请。
- 2020-3-20 提交实习生的 Resume 并完成线上性格评测以及机考（机考成绩 200/400 ）
- 2020-4-9 进行两轮面试
- 2020-4-17 收到 hr 电话通知，口头 offer get，确认入职时间等
- 2020-4-23 收到正式的实习录取邮件，网上完成个人信息填写，信息注册
- 2020-6-29 进入快手社区科学部，模型组，粗排子方向开展相应的工作
- 2020-9-2 正式提出离职。
Task Lisk: (对照着我的工作 wiki 进行回顾一下)
- 2020/6/29 - 2020/7/13 特征重要性实验 （参考了组内 leader 的实验思路 wiki）
- 分别去掉现有模型的每个特征，训练一定时间（2-3天），对比模型核心指标 ctr、ltr、wtr wuauc(weighted AUC per user)相对于未移出模型的损失。
- 优点：不会引入网络残留的影响，消除属性之间相互的影响。
- 缺点：实验代价大
- 仅在评估的时候去掉特征，对比模型核心指标相对于未移除前的损失。
- 可视化特征的参数矩阵和特征 embedding
- 缺点：只是直观感觉，没有量化指标。
- 新方法：为每个特征 embedding 增加一个DNN gate， 假设对预估指标更重要的特征会被“gate”更高比例的传入 DNN 中，重要性较低的特征会被“gate”更高比例的过滤
- 能够随着训练一次性的评估所有特征的重要性。
- 分别去掉现有模型的每个特征，训练一定时间（2-3天），对比模型核心指标 ctr、ltr、wtr wuauc(weighted AUC per user)相对于未移出模型的损失。
- 2020/7/13 - 2020/7/17 极速版 base 对齐任务并学习 mio-learner 纠错方法
- 2020/7/17 - 2020/7/25 极速版模型拆分塔实验
- 2020/7/25 - 2020/8/11 现有粗排模型总结工作
- 2020/8/11 - 2020/8/25 同城模型合并任务，模型上线，线上配置检测任务，进行线上流量实验。
- 2020/8/25 - 2020/9/1 极速版迁移mio-tf & 拆分塔模型上线，进行线上流量实验。
- 解决了 lag 问题 （模型训练出现模型）
推荐系统基础:
推荐算法的一些常用概念
| 名词 | 解释 |
| —— | —————————————————————————————— |
| 用户 | 使用某一个 App 的推荐功能的终端用户，如快手用户 |
| 物品 | 被某个推荐系统推荐给用户的标的物，如快手发现页的视频、淘宝首页的商品等 |
| 业务 | 一个具体的推荐场景，如快手发现页、同城页、关注页等 |推荐系统的输入输出
- 输入： 完成推荐，需要的原始数据大致为两类：
- 用户侧数据：即用户画像 (user profile) ，一般有两部分来源
- 静态用户信息：如性别、年龄、手机 app list 等，这些数据往往通过 server 等团队提供的服务里提供给推荐系统
- 用户动态行为：如点击列表、点赞列表、兴趣标签等，这些数据往往通过 server 透传的用户行为日志，由推荐系统内部不断更新
- 物品侧数据：在推荐中台，主要以索引 (index) 形式存在。
- 来源：一般也有两种
- 静态物品信息：如上传时间、分类等，这些数据往往通过 server 或 mmu 等内容分析团队提供的服务里提供给推荐系统
- 物品动态计数：如总点击数、点赞数等，这些数据往往通过 server 透传的用户行为日志，由推荐系统内部不断更新
- 索引的数据类型大致分为两种：
- 正排：id → list of : field name + field value 即根据物品 id 查询物品本身的各种属性
- 倒排：field name + field value → term → list of id 即根据物品的某个属性和此属性的一个具体的值，生成一个 term，在倒排索引中查询符合条件的物品 id 列表，如：播放数 = 1000 的视频列表，分类 = “二次元” 的视频列表，等等
- 索引的更新方法大致有两种：
- 批量更新：必备，一般是定时任务，最主要的索引更新功能，并且是旧索引数据删除（如视频过期，商品下架等）目前唯一的实现渠道
- 实时更新：可选，一般是消费一些离线事件，用于类似“主播关播”这种，需要实时响应（以免推荐出大堆已经关播的直播），且因为数据量太大导致批量更新时间长无法满足实时性的场景
- 来源：一般也有两种
- 用户侧数据：即用户画像 (user profile) ，一般有两部分来源
- 输出 ： 物品列表。推荐系统对一次推荐请求的响应，一般返回 N 个被推荐的“用户可能感兴趣”的物品。
- 输入： 完成推荐，需要的原始数据大致为两类：
业界数据特点:
- 类型一：预测任务相同（比如都是 ctr 预测），但是所用数据不服从同一分布等情况
- 类型二：相同或相关的数据源，但是所做的任务不同
业务流程: (并不会透露公司内部信息)
- 快手在机器学习岗位上使用了一套自研的分布式深度学习框架，封装了 tensorflow （所以说只会用PyTorch 的老铁可能会在开始遇到点麻烦，但这并不重要，因为大多数目前的模型不太会用到除了 DNN 以外的 Layer 结构），运行在公司 xlearning 平台。
推荐整体结构参考 知乎分享，公司内部实际上又将排序这一步进行了进一步细分成了触发 + 粗排 + 精排 + 重排（删除用户的 hate 的 photo / 打散）。
- 解决的核心问题：一是出于计算复杂度的限制。C = D * O，计算复杂度 C 等于候选视频数量 D 乘以单次视频评估复杂度O。我们可以在全量视频集合上使用简单算法做初步筛选，在少量视频集合上使用复杂模型做精选，这种计算范式兼顾效率和推荐效果。二是通过模块解耦，在ranking策略层面在不同模块有不同侧重点，方便各个模块针对性优化（比如召回模块侧重召回率，粗排保证高效，精排保证精准度等）。
精排的总结：（简 Reference Link: by NiuYaNan 的文档分享）
Q: 为什么双列模型的点击后事件要与 click 预测共用底层网络结构
A: 这种设计是由于双列业务中用户的双阶段交互体验决定的。click是样本中用户最稠密的反馈，click后行为数量上小一个或两个数量级，因此优化click有高ROI，用户click提升后，click后续行为也会被动提升。
单列任务上，用户交互变成单阶段，所有目标等同重要。使用相同的特征embedding层，但将不同互不相干的预测目标使用不同的顶层网络，这将一定程度上增加模型表述能力，提升模型在预测任务上的效果
Q: 为什么单列要提多任务学习？
A: 单列场景下，各个目标之间相关性较双列显著（由于所有行为都是单阶段行为）。单一目标预测性能提升不一定能够带来线上的收益。
业界推荐 展望 Reference Link: by NiuYaNan 的文档分享
- 用户长期兴趣/长期行为序列建模。长期兴趣对用户画像来说非常重要，在快手的业务中也很关键，比如召回，ranking，搜索等。业界已经有不少在用户长期行为序列建模落地的实践。
- 提升新回用户模型推荐能力。新回用户体验也是公司未来的战略重点，这是推荐模型的难点，也属于模型冷启动的范畴，比如如何突破样本固有的不平衡性，是我们要思考的问题。
- 不同数据源融合。目前的模型融合是针对单列目标的模型融合，训练的模型并不会应用到双列任务。（核心原因，单列和双列中用户行为不尽相同体现在单列用户没有click行为，也看不到视频封面，可以参考回忆一下抖音里面单列模式只有上下滑，并不能根据视频封面选择）
技术提升: (Advanced C++ 11 Vim Linux)
这一部分就不再这里总结了。主要是实习的时候读读 mio-learner 的 source code 的时候总结了一些用法罢了。
关于使用的有趣的自动化技术见之前总结的 blog
