作者 | Anthony Alford
译者 | 王强
策划 | Tina
要点
  • 基于深度学习的机器学习算法可用于响应式和个性化的广告推荐用途。
  • 各种广告平台的目标都是在长期为用户、广告客户和平台实现最大化价值。
  • 广告投放渠道包括候选检索、重量级排名、拍卖和分配，以确保在高 QPS 下实现低延迟服务。
  • 随着时间的推移，Pinterest 已将其机器学习模型从传统方法发展为更复杂的方法，例如深度神经网络（DNN）和 Transformer 架构，带来更加个性化的结果。
  • 稳健的 MLOps 实践（例如持续集成和部署（CI/CD）、模型版本控制、测试和监控）对于快速有效的迭代是非常重要的。
Pinterest 的机器学习工程师 Aayush Mudgal 在 2023 年旧金山 QCon 上发表了一场关于解析 Pinterest 广告排名系统机制的演讲。在分享中，他介绍了 Pinterest 如何使用深度学习和大数据为其用户量身定制各种广告。
与大多数在线平台一样，个性化体验是 Pinterest 的核心能力。这种个性化体验由一系列机器学习（ML）应用程序提供支持。这些程序都在尝试从平台收集的大规模数据中学习复杂的网络模式。
Mudgal 的演讲专注在个性化体验的其中一部分：投放广告。他详细讨论了如何使用机器学习方法来大规模投放广告。然后，他介绍了多种广告市场和广告投放渠道，并讨论了广告投放架构的一些典型组成部分，并谈到了两个主要问题：广告检索和排名。最后，他讨论了如何在模型训练期间监控系统运行状况，并总结了大型模型投放的一些挑战和解决方案。
内容推荐
Mudgal 首先介绍了内容推荐系统的特点。每个社交媒体平台都有数百万或数十亿个可能向用户展示的内容项目。系统目标是找到与特定用户相关的项目，但由于内容目录和用户群非常庞大，像 Pinterest 这样的平台无法预先计算每个用户与每个内容项目的相关性概率。
相比之下，平台需要一个能够快速预测这个概率的系统：快到用时数百毫秒内。它还必须提供很高的每秒查询数（QPS）。最后，它需要对用户兴趣随时间变化的动态做出响应。为了捕捉所有这些细微差别，平台需要确保推荐系统能够解决多目标优化问题。
当用户与平台上的特定元素互动时，他们通常会看到多种类似的内容。这是定向广告发挥作用的关键时刻。这些广告旨在弥合平台内用户和广告客户内容之间的差距。这里的目标是让用户接触相关内容，从而有可能将他们从平台引导到广告客户的网站。
这是一个双边市场。Pinterest、Meta、谷歌等广告平台能够帮助将用户与广告客户和相关内容联系起来。用户访问平台，接触内容。广告客户向这些广告平台付费，以便他们可以在平台上展示自己的内容，从而让用户接触。平台希望将用户、广告客户和平台的价值最大化。
广告市场
广告客户希望向用户展示他们的内容。这种做法的目的可能很简单，比如为该品牌创造知名度，或者在平台上吸引更多点击。当他们这样做时，广告客户还可以表达他们对平台上显示的特定广告的评价。
广告客户可以从两种主要竞价策略中做出选择。一种方法允许广告客户为通过平台产生的每次展示或互动支付预定的金额。或者，他们可以设定一个确定的预算，并依靠平台的算法通过自动竞价流程，以最佳方式分配预算。
接下来，广告客户还要选择他们的创意或图片内容。在投放创意之前，广告平台需要定义一个良好（good）的概率分数，以决定是否向用户投放这个特定内容。这可以定义为一次点击预测：给定一个用户和他们在平台上的活动，那么这个用户点击内容的概率会是多少？
然而，最大化点击量可能无法在平台上提供最佳的相关性：它可能会推广垃圾内容。平台有时还会有影子预测，例如“良好”点击、隐藏、保存或转发，这些预测试图从完整的层面捕捉用户的活动旅程。在某些平台上，可能有更多的广告目标，例如转化优化，试图推动更多导向广告客户网站的销售结果；这种目标很难评估，因为转化是发生在平台之外的。
此外，假设平台希望将系统扩展到更多内容类型，如视频和选集上。他们不仅需要完成上文提到的这些预测，还需要理解平台上什么样的视频点击算是良好的点击。
最后，不同的平台界面也有不同的上下文。这可能是用户的主页动态，对于这种动态而言，平台在特定时间上是拿不到任何上下文或相关性信息的；也可能是用户有意图的搜索查询。
鉴于这种复杂性，随着平台的扩展，它需要确保以高效的方式做出所有这些预测。这里做出的一些设计决策也是为了支持平台扩展和产品增长。
广告服务基础设施
Mudgal 随后对 Pinterest 的广告服务基础设施做了宏观概述。当用户与平台互动时，平台需要获取想要向用户展示的内容。用户的请求通过负载均衡器传递到应用服务器。然后将其传递到广告服务器，广告服务器返回插入到用户信息流中的广告。
图 1：广告服务基础设施宏观概述
广告服务器需要以非常低的延迟（大约数百毫秒）端到端地执行此操作。广告服务器的输入通常相当稀疏：例如一个用户 ID、这个用户的 IP 地址和当前的时间。
第一个任务是检索此用户的特征。这可能是从用户 IP 地址获得的位置，或者此用户过去在平台上的互动方式。这些通常是从键值存储中检索的，其中键是用户 ID，值是特征。
一旦该系统丰富了特征空间，它们就会被传递到候选检索阶段，该阶段会尝试筛选数十亿个内容项目，试图找到最佳候选集，以找到可以显示给用户的数百或数千个候选项目。然后，这些内容会被传递到排名服务，该服务使用重量级（heavyweight）模型来确定用户在多个目标（点击、良好点击、保存、转发、隐藏）中与内容互动的概率。
此排名服务通常还可以访问特征提取，因为系统无法高效地传输候选排名请求中的所有内容特征。通常，数百到数千个候选者会被发送到排名服务中，而一次性发送所有这些特征会让请求大大膨胀。
相反，这些特征是通过本地内存缓存（可能是 leveldb 之类的东西）获取的，并且为了确保最大化缓存命中率，可以使用外部路由层。最后，排名服务将广告发送回广告服务器。
在大多数传统的机器学习系统中，用于在特定时间内展示广告的特征值对机器学习模型的训练是非常重要的。除了获取这些特征的同步请求之外，还有一个异步请求，该请求被发送到记录这些特征的特征日志服务上。此外，为了让系统获得更高性能，还有后备候选者：如果系统的任何部分发生故障或无法检索候选者，则可以向用户显示后备候选者，这样用户始终都能在平台上看到一些内容。
广告服务器会返回广告内容并将其插入到用户的信息流中。当用户与信息流交互时，就会有一个事件日志服务，可以使用 Apache Kafka 实时记录所有这些事件。这个事件日志服务非常重要，因为如果用户与广告发送交互或点击广告，广告客户就会被扣费。
此外，广告客户必须被实时扣费，因为他们定义了一天内可以花费的最高预算。如果日志管道没有实时性能，平台可能会超出广告客户的预算，或给广告客户提供免费的展示次数。
事件日志管道还会将信息输入一个报告系统，其中包括了每小时或每日的监控系统。这个报告系统还与记录的特征有关联，因为平台希望向广告客户展示和广告效果相关的数据，这些数据与不同特征有关，例如国家 / 地区、年龄或平台上可能存在的其他特征。最后，这个事件日志服务和特征记录器一起将 Pinterest 的所有机器学习模型训练数据结合起来。
广告投放漏斗
Mudgal 随后更详细地展示了广告投放漏斗。这里分为三个步骤：检索、排名和拍卖。在检索步骤中，有数百万个并行运行的候选生成器：给定一个请求，它们的动机是获得最佳的广告候选集。这可能基于几个标准，例如新鲜内容、用户最近的互动或基于嵌入的生成器。然后将候选传递到排名模型中，该模型试图完成前文讨论的多种参与度预测。
图 2：广告投放漏斗
根据这些预测，拍卖步骤计算出在整体上下文下向用户提供特定广告的价值。根据该广告的价值，平台可以决定是否向用户展示它。此外，在这里可以处理不同的业务逻辑和分配约束：例如，平台应该将两个广告放在一起还是分开？
广告检索
广告检索的主要动机是选出具有最佳效率的最佳广告候选。这一过程使用一些非常轻量级的 ML 模型，这些模型可以以非常低的计算成本运行。模型的质量指标是召回率。
请记住，这个系统的输入是用户的 ID、内容 ID 和请求级别的特征。检索过程需要丰富的信号（signal enrichment），它使用多个基于图的扩展器，从键值特征存储中获取额外特征，例如年龄、位置、性别、先前参与率等特征对一个用户 ID 的映射。同样，内容 ID 映射到管道中预先计算的内容特征上，以减少计算需求并改善在线延迟。
图 3：信号丰富性
检索是一种分散 - 聚集方法，调用多个组件。第一个是轻量级评分和目标过滤器。评分器使用非常简单的模型来估计内容的价值。目标过滤器根据广告客户选择的标准将广告限制在某些用户子集上：例如，根据用户的位置定位广告。
图 4：检索期间的标准查询——分散聚集方法
接下来的步骤围绕预算和节奏展开。如果广告客户已用完其所有预算，则不应检索它的广告。节奏（pacing）是一个相关概念：它是一种跨时间分摊广告支出的方法。例如，如果广告预算为 100 美元，广告客户并不想在第一小时内就花掉这 100 美元，因为这样可能不会产生最佳价值。广告平台倾向于将节奏与其平台上的每日流量模式相匹配。
为了确保广告的多样性，重复数据删除功能会限制广告客户可以贡献的广告数量：平台不应该用来自单个广告客户的广告淹没整个信息流。例如，每个广告客户提供的广告中只有前 K 个候选者才允许进入下一阶段。最后，由于这是一种分散收集方法，因此可能存在不同的检索源，其结果必须混合在一起才能发送到漏斗的更下方。
下一步是候选选择和该领域的最新进展。传统上，候选检索器可以像匹配关键字或广告文案文本一样简单。随着系统变得越来越复杂，这变得越来越难以维护，也越来越难以迭代。
2016 年，YouTube 发表了一篇开创性的论文，通过引入 双塔深度神经网络 改变了这些检索系统的机制。该论文的想法是根据用户和内容的特征来学习用户和内容的潜在表示。这些表示和特征在模型中是彼此分开的。然而，如果最后用户与内容项目互动，这些表示应该非常接近，这就是模型的训练目标。
图 5：双塔 DNN [P Covington 等人，2016]
该模型的好处是可以对广告嵌入做预先计算、缓存和离线索引。广告数据库将每个广告通过模型的广告“塔”来生成其嵌入，进而构建索引。一旦在投放期间将广告编入索引，检索服务器只需调用模型的用户部分，然后利用近似最近邻搜索算法（如 HNSW）在广告数据库索引中查找相关广告。
图 6：双塔模型部署
排名模型
接下来是排名模型。从 2014 年开始，这些模型都是逻辑回归这样的简单模型。这一演变过程接下来的发展是，为了让模型更具表现力，Pinterest 从简单的解决方案转向了更复杂的模型，如 GBDT 加逻辑回归解决方案。
模型可以有四种类型的特征：用户特征；内容特征；历史中用户与内容之间的交互；最后，在此展示时间内发生的事件。模型应该学习这些特征之间的一些非线性相互作用信息，而 GBDT 在这方面很擅长。此外，该模型保留了一个逻辑回归框架，这是一个捕获高基数特征的线性模型。请注意，GBDT 不擅长处理这类特征。
图 7：GBDT + 逻辑回归集成模型
很快，Pinterest 就有大约 60 个模型投入生产了。这些模型在不断增长，产品也在不断增长。维护所有这些模型的工作变得很复杂，导致新特性采用和删除的周期变得很长，结果系统变得不够理想了。
此外，这时机器学习系统很难支持模型服务。Pinterest 使用不同的语言或框架来训练模型，而不是为模型提供服务。例如，Pinterest 过去使用 XGBoost 进行训练，然后将其转换为 TensorFlow 模型，再将其转换为 Pinterest 的服务语言 C++。系统中的这些跳跃导致了不够理想的结果，并且开发新特性的周期更长了。
最后，不断有新的广告组被创建或删除：广告的活跃期可能只有一两个月的时间窗口。Pinterest 需要模型具有响应性，以便它们能够根据新传入的数据分布进行更渐进的训练。但 GBDT 模型是静态的，没办法渐进训练它们。另一方面，深度神经网络（DNN）具有逐渐增强的训练能力。
公司的下一次迭代是用 DNN 方法取代 GBDT。DNN 带来了许多好处，但它们是更复杂的模型。这里发生的一个变化是，以前的传统机器学习算法更多依赖于手工特征工程，工程师会定义哪两个特征可能相关，模型本身无法自行学习特征交互知识。在 DNN 架构中，模型可以学习这些交互。
业内大多数推荐模型都有类似的多层架构。第一个是表示层，平台在此定义特征以及模型如何理解这些特征。在这个特定场景下，对于 DNN 来说特征处理非常重要。如果不同特征之间的特征尺度不同，模型可能会崩溃，因此该层包括了用于压缩或剪切值或对特征进行某种规范化的逻辑。
图 8：Pinterest 的 AutoML 架构
接下来，如果两个特征彼此相关，模型可以将它们汇总在一起，并学习一个共同的嵌入。之后是乘法交叉层，用于学习特征交互，然后是全连接层。
DNN 的另一个好处是跨多个目标进行多任务学习。网络重量级在不同目标（例如点击次数、转发次数或平台上可能存在的其他任何指标）之间共享，这样就无需为不同目标训练不同的模型。
该模型的下一次迭代利用了用户在平台上进行的活动的序列信息。假设用户可以与平台上的多个 pin 或多张图片交互，这些 pin 可能是与食物相关、家居装饰或旅行相关的 pin。这里的想法是，平台能否使用用户正在做的事情的这种表示来定义用户接下来可能做什么事情？
为了实现这一点，Pinterest 转向了 Transformer DNN 架构。Transformers 可以编码有关特征交互的非常强大的信息。该模型的一个关键参数是最大序列长度。随着序列长度的增加，模型大小呈二次方增长，这会影响可服务容量。
如果将序列长度增加到 100 个事件，则上述特征将变得太过复杂。相比之下，该模型使用了简单特征，例如：该操作是什么？用户是否点击了？这些特征非常简单，但较长的序列可以让模型有更大的容量。
Pinterest 最新的离线用户表示模型架构基于名为 PinnerFormer 的 Transformer 编码器。该组件从过去的用户互动（例如从昨天到一年前）中获取输入。所有这些互动都以离线方式编码，以学习每个用户的嵌入，然后可以将其用作下游 DNN 模型的特征输入。
图 9：PinnerFormer：Pinterest 用户表示的序列建模
该模型的另一个输入是来自当前用户互动的实时序列。这两者的组合可以用来了解用户正在平台上做什么事情。利用这些从 NLP 领域汲取灵感的序列，是 Pinterest 推荐系统的基础。
图 10：组合长序列
Pinterest 的 MLOps
在整个推荐系统中，以及在生产中的部署和运营方式中，机器学习只是其中很小的一部分。还有很多事情需要考虑，例如：如何确保开发团队能够更快地迭代？如何确保服务基础设施能够支持模型？如何管理资源？如何存储和验证数据？检查所有这些事项是非常重要的。
过去，Pinterest 的每个团队都有许多管道：大家都在重新构建同一个轮子。Pinterest 需要以更具扩展性的方式做到这一点。去年大多数迭代都是针对这件事的。Pinterest 构建了一个统一的、基于 Pytorch 的 ML 框架（MLEnv），该框架提供了 Docker 镜像和传统的 CI/CD 服务。需要用户编写代码的部分非常小，各种 MLOps 组件之间的集成是通过基于 API 的解决方案无缝完成的，这使得团队能够更快迭代。
标准模型部署过程使用了 MLflow，这是一个开源解决方案。当这些模型被移入生产流水线时，它们会被版本化，这样团队就可以轻松回滚。此外，模型是可重现的：MLflow 有一个 UI，用户可以在其中看到训练中用到了哪些参数。如果团队需要重新训练并重新评估训练过程，会很容易做到。
测试和监控
第一个测试步骤是集成测试。编写代码更改后，Pinterest 可以通过影子流量在生产环境中对其测试，搞清楚如果部署这个更改会发生什么事情。自动捕获的一系列指标可确保在测试过程中不会遗漏任何内容。还有一个调试系统，可以根据特定模型版本的服务重现特定请求的样子。
下一步是关于代码合并到系统中后如何发布的问题。Pinterest 遵循金丝雀、staging 和生产流水线的标准流程。每个阶段都会监控企业关心的一系列实时指标。如果每天都有偏差，或者生产环境与另一个环境之间存在偏差，则部署将停止并以无缝方式回滚。
最后，尽管采取了所有这些保护措施，错误仍然可能被漏掉。此外，广告客户的行为可能会有不一样的地方。因此，Pinterest 具有实时监控功能，可以沿着不同维度将每日和每周的模式捕获到系统中，这些维度可能是营收、插入率和 QPS。
ML 工作流验证和监控
除了监控生产指标外，ML 工作流还有其他监控要求。第一步是查看输入到模型中的训练数据集，并在此基础上定义覆盖范围和警报（例如监控特征及其随时间的变化），并确保特征是最新的。
下一组测试围绕离线模型评估展开。一旦有了训练好的模型，开发人员就需要检查该模型是否会做出正确的预测。Pinterest 会捕获 AUC 等模型指标，但他们也会捕获预测，查看预测中是否有峰值。如果有，这些问题可以停止模型验证过程。他们还监控生产中的预测峰值。
为了能够调试系统，Pinterest 开发了几种工具。关键之一是了解广告投放渠道：检索、预算、索引和广告客户。Pinterest 的工具可帮助他们定位广告从漏斗中移除的位置。
例如，假设某个广告不经常展示。如果它没有在服务端显示，则可能是因为广告质量很低，或者该广告在拍卖中没有竞争力。另一种情况可能是广告客户只想向特定用户展示广告；这是一个非常严格的检索场景，因此广告可能不会显示。
为大型模型提供服务
另一个目标是确保服务基础设施具有低延迟，这使 Pinterest 能够获得更多广告。改善延迟的一种方法是，如果模型更复杂，则转向 GPU 服务。如果这个选项不可用，则可以使用优化技术（例如量化模型或知识提炼）来改善延迟，这通常会以牺牲推理准确性为代价。
总    结
Mudgal 概述了 Pinterest 的广告投放系统，以及他们如何在生产中大规模使用 ML。他还讨论了 Pinterest 如何在部署到生产环境之前和之后监控和测试他们的模型。Mudgal 提供了一些见解，观众可以将其应用于他们自己的系统以克服类似的挑战。
作者介绍
Anthony 是 Genesys 的开发总监，他正在负责几个与客户体验相关的 AI 和 ML 项目。他在设计和构建可扩展软件方面拥有 20 多年的经验。Anthony 有电气工程博士学位，专攻智能机器人软件，并致力于解决人机交互和 SaaS 业务优化预测分析领域的各种问题。
原文链接：
Unpacking How Ad Ranking Works at Pinterest (https://www.infoq.com/articles/pinterest-ad-ranking-ai/)
声明：本文为 InfoQ 翻译，未经许可禁止转载。
今日好文推荐
谷歌大裁员引发元老集体抗议：领导脑袋空空，无能的中层管理团队不断扩大
谷歌裁掉整个 Python 团队！PyTorch 创始人急得直骂人：“WTF！核心语言团队无可替换”
德国再次拥抱Linux：数万系统从windows迁出，能否避开二十年前的“坑”？
系统 bug 致百人入狱，砸了 2.8 亿元仍上云失败！二十年了，这家大企业被日本软件坑惨了
继续阅读
阅读原文