谈谈AI落地容易的业务-搜广推

最新推荐文章于 2024-08-08 16:00:58 发布

人工智能大模型讲师培训咨询叶梓

最新推荐文章于 2024-08-08 16:00:58 发布

阅读量141

点赞数

分类专栏：人工智能文章标签：人工智能搜推广 Agent python 数据挖掘目标跟踪神经网络

原文链接：https://mp.weixin.qq.com/s/aqDS-nInC97uvLaK8J_DiA

版权

人工智能专栏收录该内容

250 篇文章 7 订阅

订阅专栏

前面谈了一下AI落地难的问题，其中谈到搜广推和量化交易/金融风控是AI相对落地能找到直接价值的业务场景，对于量化交易和金融风控而言，这两个行业算法有严格的竞业保密，基本上不会有人愿意拿出来分享，包括我只会给你说用到了图神经网络/一系列微分方程等很多算法，当然算法根本不是最重要的，如何理解业务本身和背后的人性才是最难的。

对于搜广推有一大堆公开的资料可以参考，下面就来说说这个行业吧，当然主要目的是对后面《大模型时代的数学基础(7)-图神经网络》做一个业务上的铺垫，同时也让我们明白，算法上基于传统深度学习的神经网络架构上面对业务还有很多路要走，一些底层的低维空间的关联性结构如果都用高维空间来拟合带来的算法复杂度和算力需求是非常巨大的，因此我们需要一些更巧妙的方式来降低复杂度。例如PDD砍一刀实际上是社交网络图结构上的消息传递，通过业务模式来降低复杂度，当然也有阿里妈妈”二向箔"的全量召回从算法上降低复杂度的例子。

事实上，很多人如今谈到AI就谈Transformer谈LLM，搞Agent，但还有很多算法上的机会可以供我们去仔细思考和挖掘，特别是针对不同场景落地时，需要有更接地气的处理方式，这也是我写《大模型时代的数学基础》这一系列文章的原因，无论如何，根据数据的洞察提供适当的算法并配合适当的算力并辅以相应的计算系统才是最好的演进方式，而不是简单的一招鲜吃天下，总想着爆算力来解决问题。

推荐系统通常对于普通人而言就是“啤酒和尿布”很匹配的故事，这便是早期的协同过滤算法的结果。而更让我们熟知的是字节跳动借助推荐系统把“今日头条”推向市场，然后伴随着近几年的直播等内容创作越来越丰富，推荐系统在信息过载时期提供的信息匹配价值就越来越大了。而在经济下行互联网增速放缓的时期，大多数业务的DAU增速几乎消失，推荐系统带来的效率提升更值得所有人的关注。伴随着大模型时代的到来，推荐系统能做什么也是一个值得探讨的话题。

AI在国内推荐系统的落地不得不先从百度说起，早期的搜索推荐采用竞价排名的方式，例如早期的凤巢，然后产生了一系列问题，戴文渊利用LR算法改进了凤巢，后来和陈雨强又引入了深度学习，然后雨强又在今日头条担任过架构师。文渊离开百度后去了华为诺亚方舟实验室，华为和西班牙某银行的合作中做了一些金融风控反欺诈的业务。最后文渊成立的第四范式，早期也就是为各个银行提供金融风控反欺诈相关的业务能力，然后便开始构建决策类AI产品线。

另一条推荐系统的主线就是以阿里妈妈为代表的电商广告，从盖坤2011年提出分片线性模型MLR开始，到后面通过类似于Wide&Deep算法，构建GwEN，再到后来针对用户兴趣建模提出DIN，以及将Attention和GRU引入用户兴趣构建的DIEN，但是用户兴趣序列长度有限制，又引入异步机制User Interest Center并构建MIMN算法对长期行为建模。再到后期提出Search Based Interest Model(SIM)，并针对用户不同的行为构建基于Session的分类的Deep Session Interset Network(DSIN)，在针对特征间的交互(Co Action)构建的CAN，当然还有召回中的利用树结构构建的TDM算法，和利用图结构的二项箔算法等。

针对搜索业务，我还会补充一些自己在网络运维大数据处理上的经验，例如利用图同构算法来比对和SDN配置故障归因，和通过Neo4j+Clickhouse将思科控制器搜索速度提升1000倍的一些工作。

目前业界推荐系统架构采用召回+排序两阶段模型：

但是在实际工业级推荐系统落地时会采用四阶段：

这四个环节是：召回，粗排，精排和重排。主要原因是在整个环节上对延迟有严格的需求，通常要求端到端延迟低于100ms，因此需要构建逐级过滤的算法实现。

召回通常需要对整个物料库进行大规模搜索，从海量物料中找回一部分重要物料，处理数据规模大，特别是一些大的电商平台物料库可能有数亿个SKU。同时召回规则也很多，通常采用多路召回机制

采用基于规则的召回方式，例如根据用户标签召回，根据用户兴趣类目召回，根据热销榜召回，根据高点击量，根据复购，根据质量分等方式召回。

采用协同过滤的方式，基于用户的协同过滤，或者基于物料的协同过滤

向量召回，通过物料等属性用户兴趣等，通过表示学习生成Embedding

通过如上多路召回是一种取长补短的策略，并通过查漏补缺的方式尽量满足在后续排序阶段的需求。

召回算法主要是考虑到算法时间约束下(通常分配给召回算法的时间为50ms)，尽量能够覆盖整个物料库，为后续的排序算法排除出用户不感兴趣的物料，仅留下部分匹配用户品味的物料送到排序阶段，这个阶段对算法的精度要求不高，主要是查全和速度的要求。

召回又为了查漏补缺，多路召回又增加了数据量，多路召回后的物料数量还是非常多的。而排序算法又需要尽可能的利用特征提升模型精度，因此排序算法复杂度也会快速增加。如果直接用于复杂算法排序，在算法精度(模型复杂度)和速度上的取舍是一个非常难的事情通常为了保证排序的算法的精度，也将这个阶段分成粗排和精排两个阶段。粗排主要是怕精排速度根不上而产生的预先过滤算法阶段，当然针对不同的业务场景和算法，粗排是一个可选的阶段。

精排是厂商投入资源最多的环节，是整个推荐环节中非常重要的一环。由于通过召回和粗排，候选集规模已经很小了，因此需要通过各种方法和复杂的模型结构来提升预测精度，这个地方是最容易卷的，而且离推荐系统的下游很近，对业务的影响更直接。另一方面，由于计算规模的限制，通常粗排和召回不会用用户信息和物料信息进行大量的交叉分析，而精排阶段可以充分交叉并挖掘更多的特征。

精排时，相似的内容会被精排打上相近的分数，从而在结果上集中展示。用户连着看几条相似的东西容易审美疲劳，从而损害用户体验。重排则是对精排的结果顺序进行调整，将相似的内容打散，保证用户在一屏之内看到的推荐结果的丰富性。

各个阶段简单的一个总结

阶段	约束	任务	处理数据量
召回	50ms	从海量物品中快速找回一部分重要物品	千万/亿级
粗排	10～20ms	进行粗略排序，保证一定精度并减少物品数量	万级
精排	10～20ms	复杂算法精准的对物品进行个性化排序	百/千级
重排		改进用户体验	十/百级

因为本文的重点是为后面的图神经网络和其它一些算法做铺垫，具体的内容感兴趣的可以参考王喆的《深度学习推荐系统》，对于推荐系统的演进历史，可以看看朱小强的《屠龙少年与龙：漫谈深度学习驱动的广告推荐技术发展周期》[1]，还有阿里妈妈的公众号以及其它和广告推荐相关的知乎等内容。

当然这后面还有涉及到一些广告的程序化交易的内容，例如GSP拍卖，RTB等，这些业务没有做过就不多说了。

对于任何推荐系统，其核心是人货场的匹配。早期的推荐系统，通过人以群分或者物以类聚的方式进行协同过滤开始

了对人货场的分类和定义。对于一个推荐系统，如何识别场景中上下文，如何捕获人的行为和兴趣，如何抓取货的属性，这些都是推荐系统的业务目的，至于用什么算法，用什么模型都是手段，推荐系统最吸引人的也便如此，不同的业务目标有所不同，很多时候还要面对老板们既要又要还要的多业务目标优化，手段变得更加灵活了，甚至有不少点睛之笔的算法和框架出现，甚至是用简单到极致的砍一刀商业模式来解决算法问题，令人拍案叫绝。

一个推荐系统的核心并不是某个阶段的算法或者模型，而是整个端到端的全链路干预，用户状态的理解或者重排一类的模型这些靠近端侧来做对于整个链路上的性能影响和用户体验也都有很多特别值得探索的地方。

一个工业级推荐系统，还是要从前端说起，无论是重排带来的信息丰富度，或者是UX带来的用户体验优化，UI都是非常重要的一环，而对于用户行为的捕捉和收集，对于场景的捕获这些都是前端需要考虑的。通常这些都被定义为用户理解的环节

几年前，我自己写前端的时候，通常的喜欢用React+Redux的方式，React基于State Store渲染UI，然后Redux存储状态并Cache用户历史行为，然后再通过GraphQL丢到后端，没有使用REST API的原因是用户行为的移步处理GraphQL Subscription和Mutation会更加方便。AB测试则是在GraphQL上很容易处理，相关的调用完成后再触发日志到实时流处理系统。

捕获用户的行为又不干扰用户的体验是非常值得我们去考虑的一件事情，如果埋点过多，频繁的上报会带来流量的消耗和终端的电池消耗，而埋点太少又会导致用户行为特征抽取有难度。我们在做推荐系统的时候算法和用户体验协调中可能忽视的一个小问题。

接下来就是如何利用这些埋点来抽取用户偏好，短期的兴趣和购买力评估。例如用户在搜索一些商品的时候，偶尔添加了一个过滤价格区间或者商家地域分布等，如何把这些短期行为抽取出来作为表达，这也是我个人倾向于在前端和后端间采用GraphQL这样的DSL的原因，因为分析这些会比REST API调用更加容易，返回的物料也可以更好的被在线链路理解和推理。

用户行为理解在推荐系统演进的过程中变得更加实时化，模型通常需要实时的捕捉用户的短期兴趣和意图。早期深度学习模型如下所示：

通过把过去的用户访问的商品SUM Pooling的时候其实并没有反应用户兴趣的多样性，例如一个用户过去购买或者查看过“手机”，“图书”，“登山鞋”，“冲锋衣”等，但是当前的购买计划是“耳机”，那么历史上的这些商品中“手机”对语这次购买的共享度会大一些，因此出现了DIN这样的模型，论文在《Deep Interest Network for Click-Through Rate Prediction》[2]

通过Activation Unit可以根据用户的输入来对用户行为中的不同的物料赋予不同的权重，从而获得更恰当的推荐

但是这样还不能完全的反应用户的兴趣，通常用户的兴趣上有阶段性的注意力，因此演进出了DIEN模型《Deep Interest Evolution Network for Click-Through Rate Prediction》[3]

通过GRU和AUGRU对用户行为顺序进行建模，并提取注意力的方式来构建模型：

它提出了Interest Extractor Layer和Interest Evolving Layer的概念，通过对用户行为序列的分析，GRU逐渐的在Hidden State里捕获了兴趣，并且针对不同的时间长度，又借鉴了DIN中的方法，提出了Attention机制来将相关性计算融入序列，构建AUGRU

统计分析用户行为长度序列到1000会带来1.5%的AUC提升

但是LSTM/GRU这类模型只能承受短期的行为序列长度，通常这类模型的序列长度被限制在100个左右，那么如何扩展到1000甚至更多呢？因此出现了MIMN模型《Practice on Long Sequential User Behavior Modeling for Click-Through Rate Prediction》[4]

这里主要有两个约束，从论文中看，当时淘宝电商平台存在6亿用户，用户序列长度在150时内存消耗为1TB，而当用户行为序列到1000时，存储空间消耗会到6TB，这样会对计算带来非常大的压力。另一方面模型上线有严格的时间约束，DIEN模型QPS=500时的系统延迟在14ms，当行为序列到1000时，QPS=500的系统延迟接近200ms，这是无法接受的，因此需要在算法上解决。第一个方法就是工程实现上的，通过离线计算+在线缓存的方式构建了用户兴趣中心UIC服务，如下图所示，通过UIC可以保证序列长度1000时，QPS=500的系统延迟19ms

另一方面是模型建模上采用了MIMN(Multi-Channel User Interest Memory Network)模型

原理上就是对用户的兴趣行为序列按照不同的Channel划分：

而关键的组件是NTM(Neural Turing Machine)和MIU(Memory Induction Unit)配合将6TB的数据消耗量下降到了2.7TB

但此时又导致了一个问题，虽然计算分离的方式保证了业务的延迟，但是更新频率不一致使得行为序列无法和候选物料很好的交互，MIMN在序列长度大于1000后还会因为这种不匹配的问题带来潜在的性能下降，如何捕获更长的行为极限呢？为了解决这个问题出现了SIM模型《Search-based User Interest Modeling with Lifelong Sequential Behavior Data for Click-Through Rate Prediction》[5]它采用了一个多阶段的算法，第一阶段相对粗略的搜索，提取行为序列中和候选物料相关的节点，第二阶段通过精准搜索，得到序列与候选物料的关系，并形成Embedding供后续网络使用：

第一阶段搜索上作者提出了两种算法：

Soft Search : 类似于ANN的物料召回结构，获取与候选物料相关的节点

Hard Search : 直接根据用户ID/商品类别ID/行为商品ID来构建一个索引树，根据请求直接检索

实际线上效果中发现搜索效果上虽然Soft Search相对优于Hard Search，但是Hard Search的性能更好，资源消耗更少，因此整个在线推理框架如下：

在第二阶段中，模型会将用户画像，候选物料，短期行为序列和前一步筛选出的长期行为序列整合起来，短期行为序列还是借用了DIEN模型结构，而长期行为序列中用户行为间隔跨度很长，因此行为分布不同，所以为用户行为引入了一个时间状态。

SIM能够处理的用户行为序列长度可以到54000，基本上能够覆盖用户长期兴趣建模所需的时间。

另一方面随着Flink这样的在线流计算引擎，我们可以更好的统计用户的搜索浏览信息，并按照窗口进行Session会话分割，如下所示：

因此就出现了DSIN算法《Deep Session Interest Network for Click-Through Rate Prediction》[6]

然后模型中提出了基于Session的兴趣抽取/交互/激活，模型框架上也采用了Transformer的多头注意力机制，兴趣交互则采用了Bi-LSTM，兴趣激活则是继续借鉴DIN/DIEN的方法。

精排阶段会引入一些特征交叉的处理方式，通过简单的拼接特征构成笛卡尔积的方式，但是整个推荐系统的Embedding会因为这种方式越来越重，是否有更简洁的表示方式呢？

如上右图所示，出现了CAN模型《CAN: Feature Co-Action for Click-Through Rate Prediction》[7] 更详细的内容可以看看作者周国睿的知乎文章《想为特征交互走一条新的路》[8]

最终的业务效果如作者说的，模型的效果相对于笛卡尔积的方式会更好，参数也不会急剧膨胀。

搜广推随着业务演进也会出现不同的场景，每个场景一个模型显然也不合适，一些常见的场景如下：

针对这个问题开发了STAR模型《One Model to Serve All: Star Topology Adaptive Recommender for Multi-Domain CTR Prediction》[9] ,阿里妈妈在知乎上也有一篇文章详细解释《CIKM 2021 | 多场景下的星型CTR预估模型STAR》[10]

Domain Indicator也作为特征进行输入：

当然针对多目标多场景也可以采用MoE模型，作者对比了两者之间的差异：

在场景理解中还有很多值得我们去探索的，例如短视频场景，兴趣电商场景，甚至是一些线下门店的用户行为捕获和基于场景的消费理解等，这些场景信息如何抓取并嵌入到模型中。

通常一个大规模的电商物料库中的SKU上亿，物料间的关系如何构建，如何快速的检索召回？物料的特征如何定义并构建相应的Embedding表示？物料相应的详细介绍和视频如何抽取出关键标签，这些都是物料理解相关的内容。

物料的Embedding从早期通过对矩阵分解产生“用户侧隐向量”和“物料侧隐向量”开始，然后类似于今天的大模型的Word2Vec机制构建了Item2Vec的方法，实际上广义的Item2Vec通常来自于双塔模型：

通过对用户侧特征和物料侧特征构建两个塔进行训练得到Item Embedding，但是物品间的关系有很多低维度的特征可以捕获，一种方式就是利用树状结构来构建的深度树匹配体系TDM

具体内容有两篇知乎上的文章可以参考

《阿里妈妈深度树检索技术（TDM）及应用框架的探索实践》[11]

《阿里深度树匹配召回体系演进》[12]

相关的论文：《Learning Tree-based Deep Model for Recommender Systems》[13]

《Joint Optimization of Tree-based Index and Deep Model for Recommender Systems 》[14]

《Learning Optimal Tree Models Under Beam Search》[15]

当然除了兴趣树的结构，我们是否可以用图结构来表示呢？通过图Embedding来做？这里就涉及到DeepWalk模型，Node2Vec模型图卷积模型等

当然还有利用HNSW算法进行图检索的“二向箔”技术，可以参考《TDM到二向箔：阿里妈妈展示广告Match底层技术架构演进》[16] 以及论文《Approximate Nearest Neighbor Search under Neural Similarity Metric for Large-Scale Recommendation》[17]

HNSW（Hierarchical Navigable Small Word）算法算是目前推荐领域里面常用的ANN（Approximate Nearest Neighbor）算法，简单的来说可以理解成跳表和图结构的配合

具体的内容我们会在《大模型时代的数学基础(7)-图神经网络》中详细介绍。

当然除此之外，在粗排阶段阿里妈妈还有一些COLD算法《COLD: Towards the Next Generation of Pre-Ranking System》[18]在召回和精排之间做一些过滤，下图显示了粗排的演进过程：

从最简单的统计到LR，再到向量内积的双塔模型，演进到到第四代COLD，官方的称为：Computing power cost-aware Online and Lightweight Deep pre-ranking system，灵活对模型效果和算力进行平衡，值得关注的是它在工程实现上的优化，具体内容可以参考

《阿里定向广告最新突破：面向下一代的粗排排序系统COLD》[19]

练和在线打分都是实时化的，对于模型迭代和在线A/B测试都更有利，对新广告的冷启动也有优势。

实际上这些更实时化的算法都是我们未来需要追求的地方。

对于用户和新物料的冷启动一直是一个困扰推荐系统的难题，当然也有不少的算法来解决这类问题，例如按照一些用户群组投放，根据物料描述找到相似关系，或者是利用图的方式来做链路预测等。

这一段需要强调的是，有些时候不一定真的需要用技术手段来解决，可以通过一些商业模式上的创新来解决，例如PDD砍一刀就很好的通过这种商业模式的方式来将用户的社交关系图获取了。而抖音这些直播电商的商务模式又很好的解决了物料冷启动的问题。

一般SDN设备都采用YANG Model来定义，或者是一系列在转发层面上抽像出来的Object Tree模型，一个设备的运行状态和物理拓扑路由表等大量的状态都可以构成一个图结构

通过对故障时和正常时的图同构算法对比，其实很容对故障归因。图同构的算法我们也会在《大模型时代的数学基础(7)-图神经网络》中详细介绍

另一方面，假设我们需要对一个数据包经过了哪些网络设备遇到了哪些问题进行归因分析，通常会对Netflow等日志进行搜索，但是网络中又存在NAT等地址转换信息，导致查询时需要分段索引，或者实时的基于Flow做分布式Join等当然很多公司都借助于云上的大数据平台来构建了一套分析系统，例如阿里云的vTrace或者思科的vAnalytics，但是对于一些私有云部署的设备又存在网络安全和隐私相关的担忧需要对这些数据离线处理。

当时我设计了一套基于Clickhouse+Neo4j的算法，搜索上利用网络物理拓扑和一些概率模型构建类似的HNSW搜索机制，避免了分布式Join的方式，同时数据可以采用Clickhouse分Region存放，并行搜索的处理方式。整个查询速度提升了1000x

当下我们对于AI的发展和大模型总有各种各样算力上的恐慌，引用一个ppt：

其实算力并不是约束，而是一个可以联合优化的变量。详细的内容可以看看《阿里新一代Rank技术》[20].

这也是我一直以来的观点，毕竟任何AI系统最终是要考虑ROI的，基础设施架构/算法/算力的平衡才是我们需要去追求的，你可以看到整个搜广推业务里充满了各种算力/算法/软硬件协同的优化。

大模型其实亦然，现在深度学习任务能够有效的处理大量线性空间的数据(例如空间/图像结构，文本/传感器等时间序列数据)，但是对于社交网络/推荐系统/分子动力学/药物发现/金融风控等场景的数据，而现有的深度学习算法对于这样的结构自然就有些力不从心了，事实上一些低维的对称结构，图算法的应用，以及范畴论，拓扑数据分析等领域的进展可以数倍的降低算法的复杂度。

对于未来AI的落地，我想一定是在一定条件约束下，为了完成多个可量化的业务目标而构建的。所谓的Copilot或者Agent，可能最形象的便是电视剧《繁花》中的爷叔，而一个组织中如何用好这样的决策，相互的信任，数字化决策的思维方式，还有很多路要走，毕竟你可以看到最容易落地的搜广推都充满了大量业务的知识和针对业务的特殊优化，随便丢给你一个LLM并不能接地气的去解决你业务的问题。

参考资料

屠龙少年与龙：漫谈深度学习驱动的广告推荐技术发展周期: https://zhuanlan.zhihu.com/p/398041971

DIN: https://arxiv.org/pdf/1706.06978.pdf

DIEN: https://arxiv.org/pdf/1809.03672.pdf

MIMN: https://arxiv.org/pdf/1905.09248.pdf

SIM: https://arxiv.org/pdf/2006.05639.pdf

DSIN: https://arxiv.org/pdf/1905.06482.pdf

CAN: https://arxiv.org/pdf/2011.05625.pdf

想为特征交互走一条新的路: https://zhuanlan.zhihu.com/p/287898562

STAR: https://arxiv.org/pdf/2101.11427.pdf

CIKM 2021 | 多场景下的星型CTR预估模型STAR: https://zhuanlan.zhihu.com/p/437246384

阿里妈妈深度树检索技术（TDM）及应用框架的探索实践: https://zhuanlan.zhihu.com/p/78488485