本文档提供了一个参考架构，展示了如何使用 Vertex AI 实现端到端双塔候选集生成工作流。双塔建模框架是一种强大的检索技术，适用于个性化应用场景，因为它可学习两个不同实体（例如 Web 查询和候选项）之间的语义相似度。
本文档面向开发具有低延迟服务要求的大规模推荐应用的技术从业人员（例如数据科学家和机器学习工程师）。如需详细了解用于构建双塔模型的建模技术、问题框架和数据准备，请参阅使用 TensorFlow Recommender 和 Vector Search 扩缩深度检索。
架构
下图展示了一种架构，用于训练双塔模型并单独部署每个塔，以执行不同的部署和服务任务：
图中显示的架构包括以下组件：
- 训练数据：训练文件存储在 Cloud Storage 中。
- 双塔训练：组合双塔模型使用 Vertex AI Training 服务进行离线训练；每个塔单独保存，用于不同的任务。
- 注册的查询和候选塔：在塔进行训练之后，每个塔都会单独上传到 Vertex AI Model Registry。
- 部署的查询塔：注册的查询塔会部署到 Vertex AI 在线端点。
- 批量预测嵌入：在批量预测作业中使用注册的候选塔来预计算所有可用候选项的嵌入表示法。
- 嵌入 JSON：预测的嵌入会保存到 Cloud Storage 中的 JSON 文件。
- ANN 索引：Vertex AI Vector Search 用于创建为近似最近邻 (ANN) 搜索而配置的服务索引。
- 部署的索引：ANN 索引会部署到 Vertex AI Vector Search 索引端点。
使用的产品
此参考架构使用以下 Google Cloud 产品：
- Vertex AI Training：全托管式训练服务，可让您实现大规模模型训练。
- Vector Search：向量相似度匹配服务，可让您存储、编入索引和搜索语义相似或相关的数据。
- Vertex AI Model Registry：一个中央代码库，您可以在其中管理机器学习模型的生命周期。
- Cloud Storage：适用于各种数据类型的费用低廉且不受限制的对象存储。数据可从 Google Cloud内部和外部访问，并且跨位置进行复制以实现冗余。
使用场景
为了满足低延迟服务要求，大规模推荐系统通常以两阶段系统的形式（有时以多阶段系统的形式）部署到生产环境中。第一阶段（候选集生成）的目标是筛选大量候选项，并检索由数百个项组成的相关子集，以用于下游过滤和排名任务。如需优化此检索任务，请考虑以下两个核心目标：
- 在模型训练期间，学习要解决的问题或任务的最佳表示法，并将此表示法编译为
<query, candidate>嵌入。 - 在模型部署期间，以足够快的速度检索相关项以满足延迟时间要求。
下图显示了两阶段推荐系统的概念性组件：
在图中，候选集生成会过滤数百万个候选项。排名操作随后会过滤生成的数百个候选项，以返回数十个推荐项。
本文档中的参考架构会训练基于双塔的检索模型。在该架构中，每个塔都是一个神经网络，用于处理查询或候选项特征，然后生成这些特征的嵌入表示法。每个塔都是单独部署的，因为每个塔都将用于生产中的不同任务：
- 候选塔：候选塔用于预计算所有候选项的嵌入。预计算的嵌入会部署到针对低延迟检索而优化的 Vertex AI Vector Search 索引端点。
- 部署的塔：在线传送期间，部署的查询塔会将原始用户查询转换为嵌入表示法。嵌入表示法随后用于在部署的索引中查找相似项嵌入。
双塔架构非常适合许多检索任务，因为双塔架构可以捕获查询和候选实体的语义关系，并将它们映射到共享嵌入空间。当实体映射到共享嵌入空间时，语义上相似的实体会聚集在一起，距离较近。因此，如果您计算给定查询的向量嵌入，则可以在嵌入空间中搜索最接近（最相似）的候选项。这类架构的主要优势在于能够分离查询和候选表示法的推理。这种分离的优势主要体现在以下两个方面：
- 您可以提供新的（新鲜）商品，而无需重新训练新的商品词汇。通过向候选项塔架提交任意一组商品特征，您可以为任意一组候选项计算商品嵌入，即使是训练期间未出现的商品也是如此。执行此计算有助于解决冷启动问题。
- 候选塔可以支持任意一组候选项，包括尚未与推荐系统互动的项。之所以能实现这种支持，是因为双塔架构会处理有关每个
<query, candidate>对的丰富内容和元数据特征。这种处理可让系统根据已知项来描述未知项。
- 候选塔可以支持任意一组候选项，包括尚未与推荐系统互动的项。之所以能实现这种支持，是因为双塔架构会处理有关每个
- 您可以通过预先计算所有候选项嵌入来优化检索推断。这些预先计算的嵌入可以编入索引并部署到针对低延迟检索进行了优化的服务基础设施。
- 塔的共同学习使您可以根据查询描述项，反之亦然。如果您有某个对的一半（例如查询），需要查找另一个对应项，则可以提前预计算等式的一半。预计算可让您尽可能快速地做出其余决策。
设计考虑事项
本部分提供的指导可帮助您在 Google Cloud 中开发满足您安全性和性能需求的候选生成架构。本部分中的指导并非详尽无遗。根据您的具体要求，您可以选择考虑其他设计因素和权衡因素。
安全
Vertex AI Vector Search 支持公共端点和虚拟私有云 (VPC) 端点部署。如果您想使用 VPC 网络，请先按照设置 VPC 网络对等互连连接中的说明操作。如果 Vector Search 索引部署在 VPC 边界内，用户必须从同一 VPC 网络内访问关联的资源。例如，如果您要通过 Vertex AI Workbench 进行开发，则需要在与部署的索引端点相同的 VPC 网络中创建 Workbench 实例。同样，任何预期会创建端点或将索引部署到端点的流水线都应在同一 VPC 网络中运行。
性能优化
本部分介绍在使用此参考架构在 Google Cloud 中设计满足工作负载性能要求的拓扑时应考虑的因素。
分析训练作业
如需优化数据输入流水线和整体训练图表，我们建议您使用 Cloud Profiler 分析训练性能。Profiler 是开源 TensorBoard Profiler 的托管式实现。
通过在训练作业中传递 –profiler 参数，您可以启用 TensorFlow 回调，以便为每个周期分析设定数量的批次。分析会捕获来自主机 CPU 以及设备 GPU 或 TPU 硬件的跟踪记录。跟踪记录提供有关训练作业资源消耗的信息。为避免出现内存不足错误，我们建议您先将分析时长设置为 2 到 10 个训练步，然后根据需要增加。
如需了解如何将 Profiler 与 Vertex AI Training 和 Vertex AI TensorBoard 搭配使用，请参阅分析模型训练性能。如需了解调试最佳实践，请参阅优化 GPU 性能。如需了解如何优化性能，请参阅使用 Profiler 优化 TensorFlow 性能。
充分利用加速器
在挂接 NVIDIA GPU 或 Cloud TPU 等训练加速器时，请务必充分利用它们。充分利用训练加速器是费用管理方面的最佳实践，因为加速器是架构中最昂贵的组件。充分利用训练加速器也是提高作业效率的最佳实践，因为避免空闲时间可降低整体资源消耗。
如需充分利用加速器，您通常需要执行几次迭代，即找到瓶颈、优化瓶颈，然后重复这些步骤，直到加速器设备利用率达到可接受的水平。由于此应用场景的许多数据集过大而无法放入内存，因此瓶颈通常出现在存储、主机虚拟机和加速器之间。
下图展示了机器学习训练输入流水线的概念性阶段：
在该图中，数据从存储空间读取并进行预处理。数据经过预处理后，会发送到设备。如需优化性能，请首先确定整体性能是受主机 CPU 限制，还是受加速器设备（GPU 或 TPU）限制。设备负责加速训练循环，而主机负责向设备馈送训练数据并从设备接收结果。以下部分介绍了如何通过提高输入流水线性能和设备性能来解决瓶颈。
提高输入流水线性能
- 从存储空间读取数据：如需提高数据读取速度，请尝试使用缓存、预提取、顺序访问模式和并行 I/O。
- 预处理数据：如需改进数据预处理，请为数据提取和转换配置并行处理，并对数据输入流水线中的
interleave转换进行调优。 - 向设备发送数据：如需缩短总作业时间，请将数据从主机并行传输到多个设备。
提高设备性能
- 增大小批次大小。小批次是指每台设备在训练循环的一次迭代中使用的训练样本数量。通过增加小批量大小，您可以增加操作之间的并行性并提高数据重用率。不过，小批次必须能够与训练程序的其余部分一起放入内存。如果您过度增加小批次大小，可能会遇到内存不足错误和模型偏差。
- 将用户定义的函数向量化。通常，数据转换可以表示为用户定义的函数，该函数描述如何转换输入数据集的每个元素。如需对此函数进行向量化处理，您可以一次对一批输入应用转换操作，而不是一次转换一个元素。任何用户定义的函数都有与调度和执行相关的开销。转换一批输入时，您需要为每批输入（而不是每项数据集元素）支付一次开销。
先纵向扩容再横向扩容
为训练作业配置计算资源时，我们建议您先纵向扩容，然后再横向扩容。这意味着，您应该先选择一台更大、更强大的设备，然后再使用多台功能较弱的设备。我们建议您按以下方式进行扩缩：
- 单个工作器 + 单个设备
- 单个工作器 + 功能更强大的设备
- 单个工作器 + 多台设备
- 分布式训练
评估 ANN 向量搜索的召回率与延迟时间之间的权衡
如需评估 ANN 搜索的优势，您可以测量给定查询的延迟时间和召回率。为了帮助您对索引进行调优，Vertex AI Vector Search 提供了创建暴力索引的功能。暴力索引会以更高的延迟时间为代价来执行穷举搜索，从而找到给定查询向量的真正最近邻。暴力索引不适合用于生产环境，但在索引调优期间计算召回率时，它可提供良好的基准。
如需评估召回率与延迟时间之间的权衡，您可以将预计算的候选嵌入部署到为 ANN 搜索而配置的一个索引，以及部署到为暴力搜索而配置的另一个索引。暴力索引会返回绝对最近邻，但通常比 ANN 搜索花费的时间更长。您可能愿意牺牲一些检索召回率来换取检索延迟时间的缩短，但这种权衡应进行评估。影响召回率和延迟时间的其他特征包括：
- 建模参数：许多建模决策会影响嵌入空间，而嵌入空间最终会成为服务索引。比较针对基于浅层和深层检索模型构建的索引检索到的候选项。
- 维度：维度是最终由模型决定的另一个方面。ANN 索引的维度必须与查询和候选塔向量的维度一致。
- 拥挤和过滤标记：标记可提供强大的功能，用于针对不同的生产应用场景定制结果。最佳实践是了解标记如何影响检索到的候选项以及如何影响性能。
- ANN 数量：增加此值会提高召回率，但可能会按比例增加延迟时间。
- 要搜索的叶节点百分比：要搜索的叶节点百分比是评估召回率与延迟时间之间权衡的最关键选项。增加此值会提高召回率，但可能会按比例增加延迟时间。
后续步骤
如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。
贡献者
作者：
- Jordan Totten | 客户工程师
- Jeremy Wortz | 客户工程师
- Lakshmanan Sethu | 技术支持客户经理
其他贡献者：Kaz Sato | 资深开发技术推广工程师