导读 大家好，今天将探讨推荐系统降本增效的策略。面对企业客户对成本优化的需求，我们关注于训练成本优化和开发效率提升。作为阿里云平台型产品（人工智能平台 PAI），服务的众多企业都面临类似挑战。我将概述推荐系统整个大模块，特别聚焦在特征平台（Feature Store）和算法训练工具（EasyRec与 TorchEasyRec）。EasyRec 基于 TensorFlow 框架，而 TorchEasyRec 则基于 TorchRec 开源版本进行封装和改进。推荐引擎（PAI-Rec）已开源，支持配置化召回、过滤、排序等功能，此外提供定制化的 A/B test 服务。推荐算法定制的特色是能满足不同客户的多样化需求，视频推荐、直播推荐或电商推荐，特征字段是不一样的，可通过灵活配置适应不同场景，快速构建完整的推荐系统代码。
主要内容包括以下几个部分：1. 推荐系统降本增效之路
2. 问答环节
3. 参考 URL
分享嘉宾｜钟灵 阿里云 人工智能平台 PAI-Rec 推荐系统负责人
编辑整理｜王甲君
内容校对｜李瑶
出品社区｜DataFun
推荐系统降本增效之路
推荐系统实践中面临多项挑战。一是推荐算法链路长，数据处理、样本加工、算法选型、离线调试、引擎部署和 A/B 测试等流程需手写代码，周期长（初次上线可能就要 3-4 个月），影响迭代效率。另外，特征工程在离线与在线部署中需保持一致，缺乏高效工具支持会导致维护困难。二是模型研发耗时长，当处理序列特征、整合 DNN 或引入新的 loss 时，手动修改要对模型代码进行大量的修改和调试，不仅耗时且要求开发者具备深厚的算法背景。在 EasyRec 中，组件化和配置化工具能够缩短开发周期并降低技术门槛。三是训练资源消耗大，推荐任务中很多是用 CPU 训练，但现在正在迁移到 GPU 上训练，GPU 训练相较于 CPU 能显著提升训练效率和资源利用率。四是在线推理成本高，在线推理成本取决于 QPS，实现弹性的可伸缩系统来应对不同时间段的 QPS 需求，确保成本优化。
在推荐算法定制中，面对不同企业客户的数据问题，首先通过数据诊断工具配置，识别无效特征（如缺失率高的特征）和异常转化数据（如只有点击没有曝光，或只有购买没有点击），然后分析数据留存率，确定训练周期。大型公司已有成熟的特征工程体系，而中小公司则需通过定制流程逐步完善模型的特征。模型部署后，进行特征一致性检查，确保离线与在线处理的一致性（很多效果不一致，都会发现是特征不一致的问题）。此外，运营干预工具如流量调控和黑白名单起着关键作用。流量调控适用于保证特定商品曝光占比的业务场景。要控制曝光占比相对比较简单；调控目标物品集合的点击率更为复杂，通常需优化曝光分配，将更有把握的曝光给予更有潜力去转化的用户。
推荐算法定制涉及用户表、物品表和行为表三张核心表，再通过配置确定召回和特征配置。模型输出召回和排序结果，部署至 Hologres 在线存储。PAI-EAS 负责打分服务，引擎与打分服务分离，确保高效资源利用和弹性伸缩。Flink 链路捕获实时特征，包括统计特征和序列特征，从而优化深度学习模型。当序列数据不足时，需补充传统特征工程。特征处理需保持离线和在线一致性，通过自定义 C++ 算子实现。通过推荐算法定制（PAI-Rec）串联全链路，实现高度配置化，能适应不同客户的需求，确保离线和在线功能的一致性。
这里展示了我们的用户界面，可以直观地看到数据处理、样本加工和算法选型等关键环节。针对新企业用户，整体流程大约需要四周时间。第一周专注于数据处理，第二周进行召回等配置的一键部署，并定制特征配置。通过这两周的努力，用户能够快速配置好推荐系统所需的核心要素。
第三周着手于引擎构建，包括模型训练和引擎部署。第四周部署至线上环境，首先在预发环境进行测试和一致性校验，随后即可提供服务。整个流程快速且高效，对于熟悉操作的用户，甚至能在两周多的时间内上线新场景，明显提升了工作效率。算法工程师无需关注周边工具，只需专注于选择适当的特征和序列特征。对于首次使用的客户，基于其行为日志模拟序列特征，利用历史数据在离线时生成序列，确保与线上实时数据的一致性。此外，序列特征不仅限于 ID 序列，还包括类目、品牌等多元信息，这些都被整合进系统中，能实现更精准的推荐。
物品的特征表包括基础特征表和实时特征表，实时特征如 1 小时内的点击或购买次数；也可以扩展至更长时间的统计（如 6 小时）。为了有效管理这些特征，需要一个管理平台（特征平台 FeatureStore），支持离线训练和在线应用。这主要依赖于系统工程师的工作，但与算法工程师紧密相关的是 EasyRec Processor 中的 FG 算子。FG 算子在内部处理特征，如离散化并生成分桶 ID，或构建物品 ID 序列特征。由于物品 ID 需与品牌、类目等属性实时拼接，提供完整的特征信息，这通常在打分服务内部完成，避免外部拼接带来的高延迟和推理成本的增加。
FeatureStore 集成了实时特征和离线特征管理，实时特征如物品统计信息在推荐引擎内部实时计算，确保推荐请求的即时性。底层通过 Go SDK 支持 PAI-Rec 引擎的数据读取，同时提供 C++ SDK 用于打分服务器中读取特征，以及 Java SDK 和 Python SDK 满足不同用户需求。SDK 负责从多种存储系统（如 Hologres、OTS）中读取特征，并处理实时序列特征的拼接，更新实时统计特征，确保数据的完整性和准确性。用户可灵活选择 FeatureStore 的组件来满足业务系统的需求，进行特征管理、训练和推理。
EasyRec 是一个成熟的算法框架，支持多种数据源，包括阿里云上的 OSS、MaxCompute，以及开源的 HDFS、Hive 和 Kafka。在使用这些数据前，首先识别其字段和类型（如 string 或 float），进而确定相应的特征类型（如类别特征或 ID 特征）。对于 ID 特征，如价格等数值型数据，直接将其作为特征输入模型。同时，对于序列特征，如由多个 ID 组成的字符串，采用适当的分隔符进行处理。EasyRec 提供了多种模型以满足不同服务需求，无论是针对二分类目标还是回归预测（如时长预测）。最后，会根据训练目标选择合适的评估指标（如 accuracy 或 MSE），以确保模型性能的优化。
算法本身是开源的，在训练过程中会遇到一些挑战，例如如何更快地训练或使训练过程更方便。当特征过多或模型过大时，需进行特征选择或模型蒸馏来优化性能。特别针对 CPU 上的训练做了一些优化，但这与在 GPU 上的训练优化有所不同。在推理方面，CPU 和 GPU 上的优化策略也有所差异，且推理性能对整体成本和效率有显著影响。优化后的推理性能使 QPS 大幅提升，从而显著降低成本。
打分服务的原理要特别关注右侧的特征存储、特征变换、TF 模型打分的流程。EasyRec Processor 服务在召回中分为几个关键步骤。FeatureStore Cache 针对高频高热物品的特征进行内存存储，而对于冷门物品则通过远程方式获取。Feature Generate（FG）负责特征的变换，确保离线和在线的一致性。FG 涉及的操作包括序列特征的拼接、分桶分箱等复杂处理，特别在推荐中常用的还有通过用户特征和物品特征进行 lookup 查找的操作，如根据用户的类目点击次数和物品的类目信息来查找具体值。
EasyRec 在训练和推理方面的成本优化显著。在训练上，使用 10 亿样本时，通过英伟达提供的 SDK（如 SOK）配合 EasyRec，单机四卡的性能相比原生 TensorFlow 提高了三分之一。在推理方面，将 CPU 改为 GPU 后，总体成本降低了 50%，主要得益于将大部分计算移至 GPU 上执行。此外，FeatureStore 的引入在性能和内存管理方面带来了优化，虽然它与算法本身关联不大，但对实时（RT）响应时间等整体解决方案起到了关键作用。特别指出，算法优化主要体现在 Feature
Generate（FG）部分。
通过对比 TorchEasyRec 版本在不同资源配置下的训练表现，我们发现即使在相对简单的模型上，训练资源的差异也会显著影响训练时间。与 TensorFlow 使用 120 个 CPU 相比，TorchEasyRec 尽管仅使用 2 个 A10，但其训练时间却从约 1 小时缩短至大约 10 分钟。这表明在某些场景下，快速训练模型并尽早提供模型的重要性，尤其对需要频繁更新模型或进行在线学习的场景，训练速度的提升将带来显著收益。
在组件化算法配置中，采用有向图的方式快速创建新模型。每个模型由多个小的网络组件（或称为块）组成，如 transformer、DNN 和 concat_blocks 等。这些组件按照一定的逻辑和顺序组织起来，最终构建出完整的模型。这种方式使得模型创建更加灵活和高效。
在配置化技术中，这里展示了一个简单的 Wide&Deep模型配置。模型接收两组特征：外侧特征和深度侧特征。网络主干通过多个 block 来表达，这些 block 之间存在依赖关系，共同构成完整的模型。为了灵活性允许用户搭建各种模块，甚至自定义模块并插入使用，只需遵循相应的开发协议。
PAI-Rec 引擎部分涵盖了推荐系统的核心流程，包括召回、过滤、粗排等阶段。这些阶段通过引擎从数据源获取数据，如召回的数据集、过滤后的结果以及排序所需的打分信息，从而完成整个推荐流程。
推荐引擎通常包含多个层次，如召回、过滤、排序和重排。当使用相同格式（如协同过滤或向量召回）时，通过配置文件指定即可从支持的存储中读取数据。该框架是开源的，允许用户自定义配置并在本地运行服务。若不满足需求，还可开发自定义的召回组件并集成到系统中。
AB 实验用于配置模型和算法，包括设置参数和CTR 等关键指标。通过一个管理平台，用户可以管理各层次的实验并查看报表。中间环节通过中间表来管理客户数据，并基于这些数据进行指标计算。系统了解指标间的依赖关系，能够自动计算最终指标。
一致性检查至关重要，它确保离线和实时在线数据的一致性。为实现这一点，需要配置离线和在线的服务、特征和模型，发送请求，并运行任务以进行对比。
特征一致性涉及离线与在线一致性检查。左侧描述离线流程，包括特征工程、样本处理和 FG 变换，FG 变换在离线与在线时均须执行。为验证一致性，首先发起在线请求并记录特征变换的每一步骤，如原始特征、特征处理后状态以及模型预测分数；接着使用相同特征在离线环境中再次进行特征变换和模型预测。通过比对离线与在线的预测分数，可以识别出可能的不一致特征，并进一步调查原因。这个一致性检查工具在支持大量的客户时至关重要。问答环节
提问 1：钟老师，您好！我想了解关于训练性能的绝对值。例如，10 亿样本训练提升34% 的具体时间是多少，是半天还是一天？另外，关于推理时延，系统支持的最大特征数量以及在这些特征数量下，时延的大致量级是多少？回答 1：关于训练性能，由于涉及真实客户数据，只能提供相对提升值。关于推理，系统通常支持 1000 至 1200 个特征，其中包括大量 lookup 特征和序列特征。推理时延一般在 200 毫秒以内，较优情况下为 100 至 150 毫秒。追问 1：您提到的 1200 个特征，是指每个序列特征单独计算，还是序列中的多个元素算作一个特征？追答 1：输入 FG 前有 1200 个特征，但经过 FG 处理后，特征数量可能会减少，比如两个特征合并为一个，因此特征数量可能会减少三分之一。追问 2：关于特征一致性，离线处理用 SQL，线上用 C++。如何确保两者实现一致？是否需要保证？追答 2：特征处理中，部分统计特征离线用 SQL 计算，而变换、分箱和 lookup 等特征用 C++ 实现。这些 C++ 实现的特征处理算子既用于离线也用于在线，且可嵌入深度学习模型进行推理。然而，当前推理时计算这些特征速度较慢，主要由于格式问题，如使用 string 而非 map 来存储 KV 对，正在改进这一点。此外，我们计划将 torchEasyRec 及其算法开源，但当前仍在内测阶段。算子部分的开源可能还需一段时间，我们会努力开源更多内容。提问2：钟老师，您如何看待图神经网络？前面的推演算法主要基于 Wide&Deep 和特征工程，贵司是否尝试过图神经网络？与现有方案相比，效果如何？回答2：图神经网络在社交用户召回中表现优异，尤其是在处理复杂社交关系图时。相比协同过滤，图神经网络召回效果更佳。我们之前开源的 GraphLearn 工具中就包含了 GCN 等图神经网络的工作。在客户案例中，使用图神经网络的点击率等指标提升了 50% 以上，有效召回了更多优质候选。参考 URL
CodeBase: https://github.com/alibaba/EasyRec Doc: https://easyrec.readthedocs.io/en/latest/PAI-Rec：https://www.aliyun.com/activity/bigdata/airec/pairec
分享嘉宾
INTRODUCTION
钟灵
阿里云
人工智能平台 PAI-Rec 推荐系统负责人
四川大学计算机专业硕士研究生。
具有多年搜索推荐场景的算法和工程实践经验，为数十家阿里云客户提供场景优化建议和效果优化。