内容简介：推荐策略设计的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
之前在讲搜索的时候，我也是在最后强调了AB test的重要性。推荐和搜索一样，本身极大依赖参数的配置。而这些参数的配置并没有通用的法则，同时也依赖各个平台自身具体的情况，只能在了解其原理的基础上，不断迭代摸索。在算法迭代的过程中，能够测试其效果是算法迭代的核心。只有能同时在线上部署多套搜索算法，并且监控其效果，推荐的迭代和改进才能展开。而这一切的基础，正是一个看不见的功能：AB test机制。
7. 总结
本期总结了推荐系统实现过程中一些需要特别注意的地方。
结束之前，讨论另一个问题， 推荐系统的产品经理需要懂算法么？
答案也很简单，一定要懂。如果不懂算法，就只能是做简单的评估并提出改进，很难有系统性的优化方案。懂算法也不是要知道具体怎么实现，而是要知道实现的原理，这样才能更好地把产品需求转为推荐策略，并且和算法工程师商量出解决方案。
#专栏作家#
潘一鸣，人人都是产品经理专栏作家，THU/PM，知乎专栏：产品逻辑之美
本文原创发布于人人都是产品经理。未经许可，禁止转载。
以上所述就是小编给大家介绍的《推荐策略设计的Notes》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 推荐策略产品经理：什么是协同过滤推荐算法？
- 推荐策略中的“召回”
- 以头条为例：谈谈推荐策略
- 基于Embedding的推荐系统召回策略
- 从0到1搭建推荐策略产品的思考（二）：如何搭建？
- 负载均衡策略之轮询策略
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
