保举策略设计的Notes

　

保举算法的基来源根基理表述起来比较简单，但是具体实施起来还是比较复杂。没有任何一个尺度的保举系统，可以适用全部的情形，在真正实现的过程中，需要对算法有融汇贯通的掌握，以及对业务自己有深刻的理解。本章会介绍一些碎片化的保举系统notes。

1. 要解决哪些bad case?

这个问题是保举系统被设计出来的根本，产品遇到了哪些bad case,无法通过现有的机制实现，而必然要通过保举系统才能解决?

以传统门户而言，之所以用保举系统，是因为随着受众的增多，受众对于新闻的偏好越来越多样化，而针对全体人的保举系统并不能满足所有人的需求。编纂默认只会保举绝大多数人喜欢的内容，国内的情况就是“强奸新闻”和“奇闻异兽”，但是这显然不满足高端用户的需求。相反会降低门户产品的调性，造成高端用户的流失。保举系统就可以按照差别人的需求推送差别的内容，解决这个问题。

这里的要解决的case，如下：

如何让互联网新闻偏好者的首页主要是互联网新闻而非大众新闻。如果让女性用户首页不出现大量男权色彩重的新闻，好比“强奸新闻”。

只有明确了bad case，才知道了解决问题的标的目的。

2. 设计怎样的合理路径？

保举系统最终形态是基于机器学习的保举系统，那么如果设计一个一个月就上线的保举系统，怎样既保证有效性，同时也又保证最后的合理演化?

举个例子，如果最终路径是无人驾驶电动车代步。有两种演化方案：

方案一：电动滑板 → 电动自行车 → 电动摩托车 → 无人驾驶电动车方案二：汽油动力汽车 → 混合动力汽车 → 电动汽车 → 无人驾驶电动车

方案一看似不停演进，其实每一次都是很大成本的重构。而第二个方案，则能看到清晰的技术演化路线，驾驶动力在演化，最终是无人驾驶系统的上线，而大的架构没有修改。

我一直觉得一个产品经理的能力很大程度表现在架构思维和中间版本的设计。

具体到保举系统的设计，短期内要看到效果，一开始直接上CF，是不明智的，一开始直接上基于语义分析的保举方法也是不明智的。而如果是利用现有内容信息进行人工干预的聚类，利用这个内容聚类去实现用户聚类，则更加明智一些。后续转为自动化聚类也更加合理。

3. 可调整性

保举系统最需要考虑的问题是，如果出现了问题，怎么可以快速调整来满足需求？

办法无外乎三种：提权，降权，屏蔽。

这里就要求，权重是否能够快速调整？召回策略是否能够快速调整？只有系统级别支持粒度较细的权重调整策略，以及灵活的召回策略，才能够保证策略的快速调整，保证保举系统的可持续迭代。

这也是不建议直接上线CF或者机器学习的原因，因为CF和机器学习等策略，一开始可调整性比较差，前期无法快递迭代，可能对于项目而言，就是死刑。

4. 离线评估、 灰度上线和用户反馈

离线评估是指在发布之前，需要去检验典型的bad case 是否解决。是否达成一开始的目标，如果没有，，则需要继续调整对应算法，直到能够明显解决问题。

灰度上线则也是稳妥的办法。一开始保举系统必然是充满了各种问题，所以为了解决这个问题，刚开始上线必然不能直接全量上线。正确的做法是，灰度上线一段时间期间，快速的按照用户反馈迭代算法，再考虑全量上线。

用户反馈的方案包孕但不限于：用户问卷，负反馈操作入口。典型的负反馈入口如下（今日头条）：

5. 说服别人的数据

所有改进工作效率的系统，都会触碰别人的利益。这句话话值得读三遍。

保举系统正是这样。如果没有保举系统，运营或者编纂能确定所有的位置应该摆放什么内容。有了保举系统，本来10个人做的事情可以3个人能做完。那么这个部门裁谁？没有保举系统，可能有一些特定KPI完成的余地，甚至可能有利益输送的空间，现在交给保举系统，这个损失怎么办？

另一方面，并不是所有人都有技术信仰，觉得保举系统能比运营或编纂的经验判断会比保举系统差，如果领导自己对保举系统有怀疑，这也会是一大阻力。

保举系统最开始的目标并不是要大范围的上线，而且证明本身能替代编纂或者运营，而是要能够说服别人，保举系统是可用的。这样才会减少阻力。最常见的做法是在运营或编纂不会干预的地方，上线保举策略。因为这些地方上线保举，业务数据是绝对的增量。或者如果在重要运营位上线，必然不要改变运营或者编纂最好的位置，而是在相对次要的位置增加保举模块儿。

而只有在这些位置不停迭代系统，效果足够好之后，达到能够说服别人的时候，再考虑进一步推进保举系统的覆盖率。

6. AB test