共计 3212 个字符，预计需要花费 9 分钟才能阅读完成。
导读：上篇咱们介绍了哈啰 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 预估的办法都缓缓转为因果推断的办法，同时因果推断也是一种去偏的形式。咱们目前也在建设一个因果推断的平台，不仅在营销畛域应用，也会在硬件的故障诊断以及经营的归因剖析等畛域尝试应用。
效率方面，因为人力的问题，咱们会一直的往通用模型、主动训练的方向倒退。目前咱们精准定向这一块的圈人曾经实现了自动化训练。
最初我想说，咱们的算法同学还是要用外卷来破除内卷。而破除的办法就是从新对待咱们本人的角色，以及从新的视角从新定义咱们的业务。
（本文作者：贾立）
本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。
