共计 879 个字符，预计需要花费 3 分钟才能阅读完成。
现在在做的一个项目里面的场景比较多，每一个小场景都会有一个策略，也有是模型的，目前是部分场景共用一个，但是也存在不少是单独维护。场景多，那么意味着维护的任务量还是蛮大的，所以就引出了今天这篇文章，多场景学习，试着同时基于多个场景建模。
问题
- 场景多，各个场景单独维护工作量大
- 小场景建模可能学不好，需要知识迁移
- 各个场景之间的数据分布差异很大
注意事项
一般情况下说了问题就要提解决方案，为啥这里插了一脚注意事项？想要强调的是多场景这个概念！
在我遇到的推荐场景大部分归类于以下几种：
- 瀑布流—–可以无限刷的那种，常见的就是信息流
- 相关推荐 —- 给予一个种子物料，推荐相关的
- 搜索推荐—-给定一个query 去做推荐
强调多场景是以上这几类就不适合多场景交叉建模，这里提到的多场景应该是这其中一类下面的多个场景。
比如说瀑布流，有单排和双排，在不同的页面这样子，有相同的数据特征，然后将样本放在一起建模，达到多场景学习的目的。
解决方案
1、场景特征作为输入直接加入到模型里
这种一般情况下是没有用的，为什么呢？你的input一般情况下动辄好几百个特征，场景特征屈指可数。一方面是将特征concat一起过DNN，特征比较少很难起作用，在过了DNN之后就基本上信息淹没了，很大程度下起不到你想要的作用。
2、场景特征bias
这个可能比上一个强一点，因为场景特征单独构建一个辅助网络，然后与主网络的输出共同作用与logits，也就是让场景特征能够直接影响到label，所以这个我觉得是上一个改进，既然和特征一起喂模型很难起作用，那么就直接起作用。
3、动态权重
第二个网络是对logits直接作用，这里是想对每一层都坐下干预，看上图基本上都在每一层的weight上面做一些改动，基于场景特征。详细的可以参考这篇文章
https://mp.weixin.qq.com/s/gphLbCsimD3w-IoWtdz-pg ，讲的挺好的。
总结
以上这三种方法，倾向于使用第三个。模型都还是比较好理解，就是在实践的过程中还是要注意之前提到的注意事项，还有数据特征这块都是相同的情况，当然场景特征是单独的。
