打造哈啰自动化增⻓算法闭环（下）

导读：上篇我们介绍了哈啰C端算法场景和挑战及哈啰主动增长算法。本篇主要介绍哈啰被动增长算法和哈啰增长引擎的实践。

哈啰被动增⻓算法

端内流量分发

被动增长更多是一种流量算法。我们端内的流量分发参考了广告平台，实际上它没有真正的竞价结算，但是我们把流量在各个业务线的分发之间，其实是有竞价机制的存在。这里的竞价是通过一个归因工具来做真正的价格识别，难点主要是归因工具里面的口径，需要所有业务线都认可，这需要自上而下的推动才能够完成。

另外是短期的流量效率和长期的交叉引流，我们希望一个用户尽可能在平台同时使用多个业务。这两个目标其实有一定矛盾，实际上我们可以把长期交叉引流看成LTV的价值，只要把这个价值定义清楚，其实和我们短期的GMV的目标也是可比的，可以放在同一条公式上进行竞价排名。具体的模型用的是一些经典模型，选型的思路就不细说。主要是我们的特征还不够多，特征组合在我们这特别重要，所以我们用 Autolnt会相对多一点。在某些弹窗领域，它的用户行为事件会特别强，所以我们需要更好的序列embedding，基本上会用最原始的DIN。

虚拟商城排序

比较特别的是我们这里面很多排序，它并不是实物卡券这些东西。虚拟商品和实物商品有很大的不同，第一个特点是它的item会特别的少，可能最多就几十个。另一个特点就是用户在不同的优惠券之间的选择，并不是基于像电商领域的兴趣购买做选择的，而是基于比价之类的纯理性纯利益方面的选择。所以说它的item之间是互斥的，我们用户量又很大，特征维度又少，这就导致我们这个场景其实不太适合用PointWise的方法。我们一开始尝试了PairWise之后，发现效果显著高于 PointWise，后面就改成ListWise框架，而ListWise损失函数类型用的是Softmax交叉熵。我们有一个Generator的模块来构造这个list，另外是给这个list的序列进行打分，这个我们叫 Evaluator。目前使用的模型是DCN的第二版本和Bi-LSTM。Bi-LSTM对我们的item序列特征进行抽取，后面具体的打分评估是通过DCN完成。

搜索推荐

在搜推领域，由于我们本地生活很多，比如说逛逛、门票、租车、旅游、酒店等等。因此传统的搜推的一些方法，包括召回的embedding和排序的CTR预估都有做。需要重点提的是我们在本地生活上尝试了一个二维的多目标学习，因为本地生活在主页上有一些推荐位，详情页也有一些推荐位。我们想这些不同推荐位，它的CTR和CVR预估都能用一个模型，所以参考了二维多目标学习。

另外是多域或多业务的一个模型，我们在逛逛中尝试了这个。CTR的提升比较大，让首页和详情页能够共用一个模型，每个场景都有自己的独立子网络，同时又有一个公共子网络，这样就能够博采众长。

哈啰增⻓引擎

算法组件化

哈啰最初做算法的思路，是想尽可能高效的进行整个算法体系建设，因为我们的人力很有限。所以我们不同的域有自己特色的算法，最终不同域特色算法，我们都会把它落地成一个组件，其他域的开发同学也就不会重复开发。

一个算法组件基本上分为两部分。一个是离线部分，离线部分就是一个标准的表，一个标准的任务格式，输出一个标准的结果类型，这是一个离线的组件。另一个是在线组件，会对我们不同的在线推理算法进行一些标准在线推理的代码。通过这种组件化，我们把一个新场景的接入时间从平均一个月降低到了一周到两周。

搜推⼀体化引擎

我们的搜索推荐用的是一套引擎，并不是两套，因为像垂类的业务其实是没有必要这么做的，我们现在其实本质上是在发展为一个中厂的平台。而大厂有不同的团队，共用一个引擎历史包袱很重。但搜推引擎也有一些不同，它并不是完全一样，我们也会针对搜索和推荐的不同，对搜索的QueryParser这块进行单独的意图识别组件的建设。所以我们最终的搜推是一个引擎，一体化之后能让我们的开发成本降低一半。

在搜推引擎建设之后，一个新业务想要快速对接进来，基本上是通过服务编排的方式。通过简单的配置和服务编排，再选择一些标准的算法组件，就能把一个新的场景快速的配置起来，只需要业务方对我们的数据格式以及API进行简单对接。

营销引擎

接下来是营销引擎，我们刚刚提到了营销基本会有4w2h，这些工具是在一个链路上的，怎么把它串联起来，让每个工具都用到全局的数据，以便目标也能够拉齐。所以我们要建一个数据和目标的总线，这样就需要一套引擎才能够完成。

如果不建设这个引擎会发生什么情况，大家可能看到现在有很多APP满屏都是营销弹窗，这对用户体验和效果有很大的损失。我们这边通过引擎可以让不同的投放工具或者不同的投放活动之间进行一个拉通，从而让他们的投放更有节奏，不会对用户进行过度的打扰。

L3⾃动化⽤户运营策略系统

对两轮这块，我们更进一步试点了自动化运营。我们把最初提到的很多策略，进行了一个标准化的抽象之后，沉淀了很多策略。今年很多策略可以自动的触发，有日常的有周期的。比如说梅雨季节，我们就需要很多促销，因为大家不太愿意出行或者骑车。这时候很多的促销策略会自动触发，目前大部分策略已经达到了自动化运营的水平。

重新思考C端算法

最后我们来说说做了这一年半之后，我们自己的一些认知的变化。我们最初的算法同学基本上都是在排序召回的漏斗中找一些点的优化点，这样做的话就会越做越死。一个场景刚上的时候效果很好，可能做个一两年也就优化不动了，对于算法本身也就是提效的作用，只是锦上添花。对某个业务来讲，有算法和没算法并没有一个质变，所以我们更多是工具人的角色。

而在深入业务之后，我们更多从一个新的视角，或者说从经营视角上看待整个C端算法，最终是为了提升整个公司的数字化运营的效率，而整个经营效率它是可以拆解的。我们C端其实就是做增长，刚刚提到的被动增长和主动增长，其实最终都是要落在流量上，只是看待的视角和维度不同而已。在这种新的看待C端算法的方式之后，就更容易在整个经营链路中找到一些结构性的机会，而不是最初点的机会。

最近由于疫情互联网的大环境整体并不好，算法工程师的未来会是什么样？在我看来在这种形势下，技术作为主要的驱动力是更加凸显的，而不是说削弱，因为简单的产品运营的方式进行的增长慢慢没有太多了，技术上的发力点空间还很大。所以我们认为在C端算法领域，技术的作用和地位会进一步的提升。

我们来做一个总结，在传统的技术视角下一定会越来越内卷。我们的算法同学在现在或者在未来几年一定是多面手的角色，最好成为一个业务专家，这样的话你在面中找结构性机会才会更容易。

其次，虽然Match- Rank已经玩不出太大花样，但不同的公司还是可以做微创新的。比如说我们场景中的表和别的场景就不一样，我们是大窄表。我们的用户量很大，但是特征并不是高维稀疏，所以我们会选一些非高维稀疏的模型。另外我们推的很多虚拟商品有锚定效应，ListWise在传统的电商推荐等场景不会作为一个主模型，最多在重排等里面做纠偏。另外像PU-Learning等技术，识别真正的负样本，当然还有其他的一些偏差，这种偏差在某些场景特别大，而不是我们想象中的那么少。

另外，因果推断作为我们这里确定性的趋势，我们一定会持续的发力，把各个领域CTR预估的方法都慢慢转为因果推断的方法，同时因果推断也是一种去偏的方式。我们目前也在建设一个因果推断的平台，不仅在营销领域使用，也会在硬件的故障诊断以及运营的归因分析等领域尝试使用。

效率方面，因为人力的问题，我们会不断的往通用模型、自动训练的方向发展。目前我们精准定向这一块的圈人已经完成了自动化训练。

最后我想说，我们的算法同学还是要用外卷来破除内卷。而破除的方法就是重新看待我们自己的角色，以及从新的视角重新定义我们的业务。

（本文作者：贾立）

本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者使用。非商业目的转载或使用本文内容，敬请注明“内容转载自哈啰技术团队”。