来源：NeuralTalk
作者：张雨石打开淘宝主页，会有商品的推荐。类似的，打开抖音，快手，也会有视频推荐。这些一般被称之为瀑布流模型，它的框架则是cloud-to-edge，即每次打开，客户端会向服务器发送请求，将推荐列表从服务器上拉取下来。
但是这样会有延迟问题：
- 系统反馈的延迟: 如上左图，如果用户点击了item 5, 那么云端的推荐系统在用户划到下一页之前是无法做进一步的反馈。
- 用户感知的延迟: 用户做了点击行为之后，云端的模型是在线训练的，可能会有1分钟的延迟，这样，用户在1分钟以内的操作可能不会被模型学习到，比如上左图，用户点击了item49,紧接着划到下一页，这个时候，云端模型无法学习到用户在item49上的行为。
为了解决这个问题，EdgeRec将部分模型推理的工作挪到了端上来，简而言之就是在用户手机上直接对用户行为进行特征抽取和模型推理，然后对服务器过来的item集合做重排序。下面我们一步步展开讲。
系统设计
下图是EdgeRec的系统架构。系统分为四个部分：
- Client Native: 客户端，负责三个事情：
- 刚开始的时候向服务器发送请求，得到最初的推荐结果，在EdgeRec中请求下来的item数会大于实际需要的，比如要求推荐50个，但实际会返回100个。这样才会有重排序的空间。
- 收集用户行为，判断是否要触发端上的模型模块，如果触发，会对上面得到的未显示的item重排序
- UI显示：将重排序的结果，显示在UI上。
- Model Serving: 客户端模型服务，是EdgeRec的核心，主要负责：
- 用户行为建模
- 上下文感知的重排序
- 将重排序的结果的log发送回服务器。
- Recommender System: 云端推荐系统，就是正常的推荐系统。
- 返回最初的推荐item以及它们的排序。
- 为client model serving模块存储embedding，需要的时候返回给client
- Offline Trainging: 线下训练模块。
- 采集log，训练模型
- 训练完成后，模型被切分为三部分：用户行为模型、上下文感知Rerank模型和embedding，前两个在客户端，最后一个由于太大放在云端。
系统实现
- Client Native:
- 用户行为，比如浏览，点击等，被存储在device上
- 设置了一些触发条件：
- 用户点击一个item
- 用户删除了一个item
- k个条目被浏览但是没有点击。
- Model serving
- Context-aware rerank从数据库中找到behavior的行为然后再做运算。
- 将模型分布部署在端上和云上
- 高效计算：
- User Behavior Model和Context-aware Reranking模块是独立异步运行
- User Behavior model使用RNN建模，中间状态会被存储，这样，每个新的行为的时间花费是O(1).
- 高效存储：
- embedding由于参数量巨大，无法放在device上，会以k-v的形式存储在服务器上，随用随取
- 模型版本需要对应上，在发送embedding请求的时候，需要把device当前使用的模型版本也放到request里。
模型
接下来，我们再详细看看User Behavior Modeling和Context-aware Reranking模块。
定义问题
首先，定义问题：
- 我们需要对从服务器上拉取下来的列表进行重排序。
- 我们知道的信息包括:
- xi: 第i个item的特征
- s: 上下文信息
- C: 实时用户行为上下文。
- 目标就是学习一个函数，对每个item进行打分。即：φ(xi, s, C)
- 函数φ可以是RNN，也可以是Transformer。
特征系统
其次，再来看一下特征系统，之前的模型在特征提取上有几个问题：
- 只考虑positive feedback，比如用户点击。没有考虑negative feedback。这是因为正向反馈更直接，没有噪音。但负向反馈也十分重要，应该考虑
- 之前的模型只考虑用户点击item的元信息，比如商标，类别等。用户在item上的行为信息也需要考虑进去。
- 比如用户点进商品详情页以后的行为。
- 比如用户在滑动过程中的停留时间
- 用户特征的实时性，在edgeRec中，用户行为无需传送到云端，全是在端上，所以可以采集更丰富的特征。
由此，需要采集的特征就有三类：
- Item Exposure User Action Feature, 即用户在列表页的行为特征
- Item Page-View User Action Feature, 即用户在商品详细页的行为特征。
- Item Feature, 商品元特征。
如下图:
所有特征细节如下:
模型
终于说到了模型部分，EdgeRec采用的模型是异构模型，即有多个部分分别对不同的信息建模。
提出的模型名字是HUBSM，即Heterogeneous User Behavior Sequence Modeling。
模型结构可以看下图，c图是模型的主结构，看起来跟山一样。
模型的异构性主要体现在两个方面：
- Item Exposure和Item Page-View的分别建模，这点反应在上图就是山的两翼。
- 用户行为和对应item的分别建模，因为用户行为和商品信息分属两个特征空间。这点反映在图上就是山的两边每一遍都是两部分encode，然后再fusion的，fusion的方法就是concat。
Item Exposure和Item Page-View部分的建模也很类似，都是分别使用GRU对action序列和item序列分别进行处理。
接下来就是reranking模块，仍然是使用GRU对候选item集合进行encoding，候选item的顺序就是服务器返回的初始排序。
在得到每个候选item的encoding后，分别去和Item Exposure中的item和Item Page-View的item的encoding去做attention计算，然后得到的权重去加权Item Exposure和Item Page-View的encoding。这个操作类似于Transformer中的attention，区别在于在这里Q和K在一个空间内，都是item，V是另外一个空间，是item和behavior的encoding拼接起来的。
实验
线上效果提升1.57% PV, 7.18% CTR, 8.87% Click, 10.92% GMV。对于淘宝这个已经优化了很多的系统来说，是巨大的提升了。
参考文献
=======
- [1]. Gong, Y., Jiang, Z., Feng, Y., Hu, B., Zhao, K., Liu, Q., & Ou, W. (2020, October). EdgeRec: Recommender System on Edge in Mobile Taobao. In Proceedings of the 29th ACM International Conference on Information & Knowledge Management (pp. 2477-2484).
往期回顾
本作品采用知识共享署名-相同方式共享 4.0 通用许可协议进行许可。
欢迎关注公众号，关注模型压缩、低比特量化、移动端推理加速优化、部署。
更多嵌入式AI相关技术干货请关注嵌入式AI专栏。
