智能推荐架构演进

为何架构演进

   为了支撑业务的发展，必须快速上线、快速试错。因此，在此阶段，各个业务线独自建设推荐系统服务，按照各自业务的特殊需求进行各自迭代，快速支持推荐策略上线落地应用到具体的业务场景，也就是我们所熟知的“烟囱模式”。此种模式各自为战，非常灵活，能够快速支持业务的个性化需求，但随着业务规模的逐渐扩大，这种“烟囱模式”的缺点就凸显了出来；算法工程师与系统工程师都要不断重建轮子，当业务没有大增长情况下，工程师位就会不断在重复某类工作，重复而繁琐的事变多后就会让人产生厌倦，得不到技术成长 ，对公司来说也没有得到沉淀，当业务继续扩张下去，效率问题会阻碍公司前进。

18年架构

从18年开始，整个推荐开始从小作坊转向正规军前进，开始将重复造轮子的事，不断抽象优化，往平台方向靠拢；

随着推荐业务场景越来,开发效率变成很重要，堆人力再也不能彻底解决效率问题，所以就有了推荐策略平台V1的搭建设计出来，开始可以解决多种业务场景重复开发、与业务方开发对接效率问题，还可以多种业务场景做初步abtest，多业务场景多策略同时跑起来，不用再硬编码方式 解决。

 

19年架构

2019年，推荐的业务开始在直播、搜索展开，支持各业务多个场景的优化；

整体架构多了一些改进，新加了ab测试实验平台V1,解决了流量交叉实验，可以让abtest策略实验跑的更多，更有效率。还有解决了不同场景abtest互相影响，导致指标判断问题。除了这个，搜索也开始加入了策略平台的改造，为了避免互相影响，以及搜索可能有更多的个性化，单独为搜索加多一个搜索策略平台，然后把搜索也大力重构，可以方便搜索做多个场景多个策略开发运行跑起来，大大提高了搜索的优化效率。

还有因为排序模型在线跑起来需要的特征服务，在这个基础上设计了特征平台初版，解决了很多特征处理的问题，包括离线训练与在线服务特征处理不一致、特征管理，特征更新等等问题

同时因为业务场景增多，策略使用的各种模型对应的接口，模型版本，模型的更新，各种问题也开始突出，所以也构造了我们自己的模型平台服务，解决这类的问题。

 

 

2020年架构

2020年，除了升级了各个平台的功能，也新增加了对于 社交业务的支持，比较重要的是构建机器学习平台；

主要期望通过强大易用的功能，来辅助算法研发人员，帮助大家脱离繁琐的工程化开发，把有限的精力聚焦于算法策略的迭代上面,目前也把所有的业务都搬迁到机器学习平台，整体运作效率提升不少；整个平台构建过程中，也让我们学习到很多东西，平台不应该至顶向下设计，工程师可能对于算法的痛点了解不够深，所以整个过和不断与算法工程师沟通磨合，不断地打造 一个适合他们，也真能降低大家的成本 ，让大家真的是觉得这个平台真真切切产出价值，让大家效率变高了，不是为了做平台而做平台。