背景

闲鱼作为电商场景的APP，最丰富的部分就是作为商品宝贝浏览承载的feeds，比如首页下面的宝贝信息流，搜索结果页以及详情页下面的猜你喜欢，这些feeds场景都少不了推荐算法在背后的支撑。

我们观察到随着手机计算能力的提升，某些计算可以在端上直接计算，再统一上报到后端，这样相比云计算有很多明显的优势：

1. 更加实时性：我们可以在端上完成原始特征的处理和实时打分，从原始特征的抽取到计算结果的上报完成，可以在1s左右完成。

2. 计算资源的节约：大量数据如果都汇集到云端上计算，可能会造成计算资源的不足，我们可以将计算量分散到各个端上，可以降低计算资源开销。

3. 多维度数据采集：一些类似于细粒度的行为数据、采集频率过高的数据或者涉及用户隐私的数据等，可以在端上直接消费掉而不需要上传。

马里奥

介绍

马里奥是闲鱼首页的一个创新形式的业务，其业务逻辑是：用户在闲鱼首页feeds部分点击来一个宝贝卡片，那么同时就会请求云端，根据后端算法拉取回来算法召回的query词和对应的推荐宝贝信息，以四个方块的形式展示在一个张卡片中，这样来给用户点击之后，跳到二级承接页面来给用户推荐更相关的宝贝，来达到提升首页feeds部分点击率和成交的效果。

效果图:

初始版本流程图:

问题

初始上线之后，我们统计马里奥卡片一跳和二跳的ctr，发现并比不上普通的宝贝，那么问题出在了哪里呢？

思路分析

闲鱼上每天都会诞生数以亿计的商品点击，这里有个很自然的问题：用户对他的这次商品点击满意吗？考虑两个简单的例子：

1. 用户点击商品后，在详情页面上停留时间很短，那么我们可以认为这可能是次误点击。

2. 用户点击商品后，他在这个详情页面上有很多的行为，比如他可能查看了产品参数、商品的颜色尺码、或者又点击了该商品的全部评价，最后还通过和卖家进行了聊天，那么我们就认为这可能是次真实意愿的点击，或者说他对这次点击满意度分很高。

那么很自然的，我们推测，只有在满意度较高的情况下，我们去做关联推荐才是有意义和有价值的，否则如果用户误点击的情况，我们也去推荐，只会适得其反，对此我们进行了解法的尝试。

解法

在这个场景下，需要在用户点击进入宝贝详情，然后离开详情页的时候，就需要给出用户对该宝贝的意向，只有满足某个阈值的情况，才应该出现马里奥卡片。这种场景下，如果使用传统的云端算法，把数据都收集好，再计算出结果，再返回到端上，这时候很可能插入卡片的时机早就过去了，没法抓到用户这个关键点。因为用户在浏览详情页的过程中，所有的点击和曝光都是在端上实时产生的，很可能在最后一刻退出页面之前，用户都在一直产生有价值的动作，这时候不断的往云端回传数据再计算，显然是不可行的方案。

当用户在闲鱼Feeds页点击推荐商品（如上面左图的汽车玩具商品）后，进行触发并展现马里奥（如上面左图虚线红框所示），引导用户进行搜索并进行更多商品点击和下单。不同于Feeds里一般的推荐项，马里奥的每一次触发其实是存在触发成本的。一个显然的成本是马里奥的触发会挤占后续商品的展现。如果用户每一次详情页点击后都触发马里奥，那么就会有大量的马里奥被展现，并挤占相应的Feeds坑位。当马里奥点击率相比Feeds过低的时候，将影响整体Feeds的展现效率及用户体验。

解法流程图:

因而在推荐流和搜索结果流中，触发型展现一个显而易见的成本是，当前触发的内容展现会压缩后续推荐的内容展现。从更高效的流量分发角度来看，对这类展现的控制是有必要性的。

不同于此前纯云端的触发展现，云端此前更多做内容侧的控制，基于用户与内容的匹配程度去决策是否展现以及展现什么。而端侧用户更加实时、更加详细、更加细粒度的行为，更偏好与刻画用户交互习惯以及对当前触发模块的需求。

为此，我们提出了智能展现模型，通过用户在端侧的细粒度交互行为建模用户对触发模块的实时偏好，将原始的触发展现模块解耦为两部分:

1. CTR(端):端侧做展现控制：基于用户当下细粒度交互行为及交互习惯决定是否请求（展现）相关模块

2. CTR(云):云侧做内容控制：决定展现的相关内容

所以我们最终采用端计算和云计算结合的方案，所有依赖数据都实时在端上产生，而且计算处理数据的过程也在端上，借助于集团提供的端计算容器，我们可以很方便的把模型部署到端上并运行它得到我们用户点击之后对点击宝贝的满意度的数值。

效果

新的马里奥方案，对整个链路和现有体系是最小侵入，也让整体更加简洁。闲鱼马里奥项目上，马里奥服务端请求量减少了-28.0%，点击率提升+31.1%，成交率增长了10%。