工业级推荐系统进阶：从多级流水线到生成式新范式

MekoLi29
4 阅读33分钟

摘要

本报告系统梳理了工业级推荐系统的核心架构设计与前沿技术演进。内容涵盖：推荐系统的总体分层架构、工程侧高并发低延迟实践（以得物DGraph引擎为例，展示如何实现毫秒级召回）、算法侧召回/排序/重排的模型演进（以爱奇艺多兴趣召回实践为例，CTR提升28%）、业务专题（多目标优化、冷启动、多场景迁移），并重点剖析快手OneRec生成式推荐系统的技术突破——通过端到端生成式架构将运营成本压缩至传统方案的10.6%，GMV提升21.01%。最后，展望大语言模型与推荐系统融合的未来趋势，总结可落地团队的架构演进与算法迭代建议。

1. 引言：推荐系统的价值与挑战

1.1 推荐系统的核心地位

在当今互联网产品中，推荐系统已从“可选项”变为“必选项”。无论是短视频、电商、信息流还是音乐平台，推荐算法都是用户增长、留存和商业变现的核心驱动力。根据行业公开数据，头部短视频平台超过70%的观看时长来自推荐流；电商平台推荐带来的成交额（GMV）占比可达30%以上。推荐系统本质上是一个“流量分配者”，它决定了用户看到什么，进而影响用户行为和商业价值。

1.2 工业级推荐系统面临的挑战

然而，构建一个高性能、高效果的推荐系统绝非易事，主要面临以下挑战：

  • 海量规模：用户数亿，物品数千万甚至上亿，实时请求QPS可达数十万甚至百万级。系统必须在毫秒级返回结果，对存储、计算、网络都是巨大考验。
  • 实时性要求：用户兴趣随时间动态变化，新内容不断产生。系统需要秒级捕捉用户最新行为并更新推荐结果，否则推荐将滞后于用户兴趣。
  • 多样性目标：推荐不仅要考虑点击率（CTR），还需兼顾时长、点赞、收藏、转化、完播率等多重目标，且目标间可能相互冲突。
  • 公平性与偏差：推荐系统容易放大数据中的偏见（如位置偏差、流行度偏差），导致马太效应，损害用户体验和系统健康。
  • 冷启动问题：新用户和新物品缺乏历史交互数据，难以精准推荐，影响用户留存和内容生态。

1.3 本次分享的重点

本次分享将围绕上述挑战，结合一线互联网大厂的实际案例，深入剖析推荐系统在工程架构和算法模型上的演进路径。我们不仅会介绍成熟的技术方案，还会展示最新的前沿探索，如生成式推荐、大语言模型融合等。希望通过本次分享，能帮助团队同学理解推荐系统的全貌，并从中获得可落地的启发。

2. 推荐系统总体架构

一个成熟的工业级推荐系统通常采用分层漏斗架构，如下图所示（文本描述）：

数据层 → 召回层 → 粗排层 → 精排层 → 重排层 → 服务层

2.1 各层职责

  • 数据层：负责用户行为日志的采集、清洗、存储，构建用户画像和物品画像，生成离线训练样本和实时特征流。常见技术栈：Kafka、Flink、Hive、HBase、Redis。
  • 召回层：从海量物品库中快速筛选出用户可能感兴趣的候选集（通常千级别），目标是“高召回、低延迟”。多路召回并行，如向量召回、热度召回、协同过滤等。
  • 粗排层：对召回结果进行初步排序，使用轻量级模型进一步过滤，将候选集降至百级别，减轻后续精排压力。
  • 精排层：使用复杂模型（如DeepFM、DIN、MMoE）对候选物品进行精准打分，输出最终排序分数。这是系统最核心、计算最密集的环节。
  • 重排层：在精排基础上，加入多样性控制、业务规则（如去重、插入广告）、上下文感知（如已曝光过滤），形成最终展示列表。
  • 服务层：封装推荐服务，提供API接口，包含ABTest分流、限流熔断、降级等稳定性保障。

2.2 漏斗思想与系统权衡

整个推荐流程是一个典型的漏斗：从千万级物品逐步过滤到几十个最终展示项。每一层都在“精度”和“效率”之间做权衡。召回层追求覆盖率和速度，允许一定程度的低精度；精排层追求极致精度，但计算复杂；重排层则关注用户体验和业务约束。设计时需根据业务场景和硬件资源合理分配算力。

2.3 核心数据模型

  • 用户画像：包含静态属性（年龄、性别）、动态兴趣标签、统计特征（历史点击率）、序列行为（最近点击的item id）等。
  • 物品画像：包括内容属性（类别、标签、作者）、统计特征（曝光量、点击率）、多模态特征（图像embedding、文本embedding）。
  • 上下文特征：时间、地理位置、网络环境、设备类型等。

2.4 大厂如何支撑亿级规模

以阿里为例，其推荐系统采用“分层+分区”架构：通过用户分片、物品分片，将数据分布到多组服务器，每个请求仅路由到部分分片，避免全量扫描。同时使用异构计算（CPU+GPU）和模型并行/数据并行训练，支撑千亿级参数模型。离线与在线一致性方面，阿里开发了Feature Store（特征存储）和在线样本生成系统，确保训练和推理使用完全相同的特征逻辑，减少线上线下不一致导致的指标波动。

3. 工程侧：高并发、低延时、实时计算的架构实践

工程架构是推荐系统的骨架，决定了系统能否稳定、高效地承载业务。本节将从数据流、召回、排序、重排服务四个方面展开，结合真实案例讲解关键技术点。

3.1 数据流与实时计算

3.1.1 数据管道选型与优化

现代推荐系统对实时性要求极高，用户的一次点击可能在几秒内就要影响下一次推荐。因此，实时数据流至关重要。典型架构如下：

  • 日志采集：客户端埋点日志通过HTTP或RPC上报至服务器，或直接写入消息队列。
  • 消息队列：Kafka是事实标准，具备高吞吐、持久化、可重播等特性。部分场景选用Pulsar，因其支持更灵活的分区模型和更低延迟。
  • 实时计算：Flink是主流选择，支持Exactly-Once语义、状态管理和事件时间处理。Spark Streaming也用于部分批流一体场景。

案例：某短视频平台Flink优化
该平台每日处理数百亿条用户行为日志，Flink作业高峰期延迟从分钟级优化到秒级。优化措施包括：

  • 调整Kafka分区与Flink并行度匹配，减少数据倾斜。
  • 使用RocksDB作为状态后端，并开启增量检查点，降低状态恢复时间。
  • 针对高频特征（如用户最近点击序列）使用异步I/O访问外部存储，避免阻塞。

3.1.2 特征生产：实时、离线、近线融合

推荐特征分为三类：

  • 离线特征：通过离线ETL（如Hive/Spark）计算，通常天级更新，存储在HBase或Redis中。
  • 实时特征：通过Flink计算滑动窗口内的统计量（如过去5分钟点击次数），写入在线存储。
  • 近线特征：介于离线与实时之间，小时级更新，常用于用户长期兴趣。

特征存储选型考量：

  • Redis：内存数据库，适用于小规模高频访问的KV特征。但存储成本高，大数据量下需要分片。
  • HBase：适合海量特征，支持按rowkey快速查询，但延迟略高（毫秒级）。
  • FAISS/向量检索库：专门用于向量特征的检索，支持ANN索引。

案例：美团外卖特征平台
美团外卖构建了统一的特征平台Feature Store，支持离在线特征一致性校验。通过定义特征元数据，自动生成离线Hive表和在线Redis存储，并定时同步。在双十一期间，特征服务QPS达到千万级，平均延迟<2ms。

3.1.3 样本生成：实时拼接与采样

训练样本由“特征+标签”构成。实时样本生成流程：

  1. 用户行为流（点击、曝光、转化）进入Flink。
  2. 根据曝光日志拼接用户特征和物品特征（从在线存储获取）。
  3. 过滤无效样本，进行负采样（通常负样本是正样本的3-10倍）。
  4. 输出到Kafka或直接写入训练文件。

解决正负样本不平衡：

  • 随机负采样：从全量物品中随机选取未点击物品作为负样本。
  • 曝光未点击负样本：用户曝光但未点击的物品作为负样本，更符合实际分布。
  • 混合采样：结合上述两种，并动态调整采样率。

3.2 召回服务架构

3.2.1 多路召回策略的工程实现

召回阶段通常并行执行多种策略，如：

  • 向量召回：基于用户和物品的embedding进行相似度检索。
  • 协同过滤：ItemCF、UserCF，基于共现矩阵。
  • 热度召回：全局或分类下的热门物品。
  • 社交召回：好友喜欢的内容。
  • 地域召回：基于LBS的附近内容。

工程实现模式：

  • 每种召回源封装为一个独立的召回器（Recaller），由召回服务统一调度，并发执行。
  • 召回器之间通过future/promise异步调用，汇总结果后合并去重。
  • 召回结果包含分数和来源标签，便于后续排序使用。

3.2.2 向量检索技术

向量召回依赖ANN（近似最近邻）算法。常用算法：

  • HNSW（Hierarchical Navigable Small World）：基于图的算法，召回率高，索引构建快，适合内存存储。
  • IVF（Inverted File Index）：基于聚类和倒排，节省内存，适合磁盘+内存混合。
  • 乘积量化（PQ）：压缩向量，减少存储，但精度略有损失。

分布式向量索引：
当物品规模达到亿级时，单机无法承载全量索引。常见方案：

  • 分片：将物品按ID哈希分到多台机器，每台构建局部索引，查询时广播给所有分片并合并结果。
  • 复制：将全量索引复制到多台机器，分摊查询压力，但存储成本高。

案例：得物DGraph召回引擎
得物App在2024年双11期间面临百万QPS的召回压力，自研了DGraph分布式图检索系统。DGraph的特点：

  • 支持多种索引（KV、倒排、向量）混合存储，满足多路召回需求。
  • 采用算子执行框架优化，通过M:N分组线程池和无锁化调度，在高负载（CPU>60%）下仍保持稳定的毫秒级延迟。
  • 将召回任务垂直拆分到多个集群，每个集群负责一部分召回源，避免互相干扰。
  • 向量检索使用HNSW+PQ量化，将内存占用降低70%，召回率保持95%以上。

效果数据：DGraph上线后，双11期间峰值QPS达120万，TP99延迟<20ms，系统可用性99.99%。

3.2.3 召回效果监控

召回层需要实时监控以下指标：

  • 召回率：通过离线模拟或在线A/B测试计算，看最终排序中有多少item来自各召回源。
  • 覆盖率：召回结果覆盖的物品占总物品的比例，反映多样性和冷启动能力。
  • 延迟：各召回源的耗时，便于定位瓶颈。
  • 重复度：多路召回之间的重复比例，过高说明策略冗余。

监控体系通常基于日志实时计算，并设置报警阈值。例如，当某路召回量突降或延迟飙升时，及时告警。

3.3 排序服务架构

3.3.1 粗排与精排分离

为什么需要粗排？
召回层输出候选集通常有数千个，若直接进行精排（复杂模型），计算量过大，延迟不可接受。粗排作为轻量级过滤器，将候选集快速压缩到几百个，为精排争取时间。

粗排模型设计：

  • 双塔模型：用户塔和物品塔分别计算embedding，在线时用内积近似相关性，速度快。
  • 轻量级DNN：少量全连接层，特征维度小，可使用CPU推理。
  • 向量召回复用：有些系统直接使用召回阶段的向量得分作为粗排分数，无需额外计算。

案例：阿里的粗排实践
阿里妈妈广告系统使用“特征工程+LR”作为粗排，后来升级为双塔模型。通过共享底层embedding，粗排与精排的得分一致性从0.6提升到0.85，粗排筛选的候选集质量更高，精排点击率提升5%。

3.3.2 精排模型推理优化

精排模型通常采用深度神经网络，参数量百万到十亿级，推理延迟要求毫秒级。优化手段包括：

  • 模型压缩：
    • 量化：将FP32模型转为INT8，推理速度提升2-4倍，精度损失<1%。
    • 蒸馏：用大模型（teacher）指导小模型（student）训练，小模型保持接近大模型的效果。
    • 剪枝：移除冗余神经元和连接。
  • 异构计算：
    • GPU适合批量推理，延迟略高但吞吐大；CPU适合单请求推理，延迟低。可将精拆分为两阶段：先用CPU处理特征拼接，再将batch送到GPU计算DNN部分。
  • 请求合并：
    • 服务端将多个并发请求合并为一个batch，提高GPU利用率。但需控制batch大小和等待时间，避免延迟增加。
  • 缓存策略：
    • 用户特征和物品特征预加载到本地缓存，减少网络访问。
    • 对热门物品的推理结果可短时缓存，降低计算压力。

案例：爱奇艺精排优化
爱奇艺随刻推荐系统采用GPU推理，但初期延迟较高。优化措施：

  • 使用TensorRT对模型进行FP16量化，延迟降低40%。
  • 引入请求合并机制，将4-8个请求合并为一个batch，GPU利用率从30%提升至70%。
  • 用户特征缓存到本地，减少Redis访问，整体TP99从15ms降至8ms。

3.3.3 延时光环：端到端延迟拆解

一个典型的推荐请求延迟构成：

  • 网络传输（客户端到服务端）：5-10ms
  • 召回层：多路并发，最慢的一路决定整体召回延迟（如向量检索10ms）
  • 特征获取：从Redis/HBase获取用户和物品特征（10-30ms）
  • 粗排：5ms
  • 精排：10ms（GPU）
  • 重排：2ms
  • 其他（序列化、反序列化）：5ms 总计约50-70ms。

优化技巧：

  • 预计算：将一些不经常变化的特征提前计算好，如用户长期兴趣embedding，减少在线计算。
  • 异步化：召回与特征获取并行执行，减少等待时间。
  • 降级方案：当某依赖超时时，快速返回默认值或使用缓存，避免整个请求失败。
  • 边缘计算：部分计算下沉到CDN边缘节点，减少网络跳数。

3.4 重排与服务化

3.4.1 重排策略

重排层主要解决精排结果的“同质化”问题，引入多样性、业务规则和上下文感知。

  • 多样性控制：
    • MMR（最大边际相关性）：在相关性基础上减去与已选物品的最大相似度，平衡相关性和多样性。
    • DPP（行列式点过程）：从候选集中选择一个子集，使得子集的行列式最大，等价于选择高质量且多样化的集合。DPP有闭式解，但计算复杂度高，常用贪婪近似算法。
  • 业务规则插入：
    • 已曝光过滤：确保用户不会短时间内重复看到同一内容。
    • 打散：同一作者或同一类别的物品不能连续出现。
    • 插入广告：在自然结果中插入广告位，并满足竞价排序。
  • 上下文感知：
    • 滑动窗口去重：在滑动窗口内控制相似内容密度。
    • 时间衰减：对最近曝光的物品降权。

案例：抖音重排多样性
抖音在重排阶段使用了DPP算法控制视频多样性，实验表明，引入DPP后用户人均观看时长增加3%，完播率提升2%。同时结合位置偏差校准，确保低位的优质视频有机会被看到。

3.4.2 服务稳定性保障

推荐服务作为线上核心接口，必须保证高可用。

  • 熔断：当依赖的下游服务（如画像、召回）连续失败超过阈值，熔断器打开，快速失败。
  • 限流：基于令牌桶或漏桶算法，防止突发流量压垮系统。可按用户等级、API方法分别限流。
  • 降级：当系统压力过大时，关闭非核心功能（如多样性算法），只返回精排结果；或返回缓存结果。
  • 灰度发布：新模型或新策略先在小流量上线，观察指标，再逐步放量。
  • ABTest平台架构：
    • 分流服务根据用户ID或设备ID分配实验组，保证一致性。
    • 实验参数可动态配置，实时生效。
    • 日志打上实验标签，便于后续效果分析。

案例：双十一峰值应对
某大厂双十一期间，推荐QPS飙升至平时10倍。应对措施：

  • 提前扩容，并启用弹性伸缩。
  • 核心服务部署多机房，进行异地多活。
  • 降级策略：非核心召回源（如社交召回）关闭，只保留向量和热度；精排模型切换为轻量版；特征缓存时间延长。
  • 全链路压测，提前发现瓶颈。

4. 算法侧：召回、排序、重排序的模型演进

算法是推荐系统的灵魂，决定了推荐效果的天花板。本节将系统介绍召回、排序、重排序领域的主流模型演进，并穿插大厂实践案例和数据。

4.1 召回算法

4.1.1 传统召回

  • 协同过滤（Collaborative Filtering）：
    • ItemCF：基于物品共现矩阵，推荐与用户历史喜欢物品相似的物品。优点是实现简单，可解释性强；缺点是稀疏性问题，无法处理新物品。
    • UserCF：基于用户相似度，推荐相似用户喜欢的物品。适用于用户数较少的场景。
  • 矩阵分解（MF）：将用户-物品交互矩阵分解为用户隐向量和物品隐向量，通过内积预测评分。代表算法：SVD、SVD++。
  • FM（Factorization Machines）：引入特征组合，可处理多域特征，是CTR预估的早期经典模型。

4.1.2 向量召回

向量召回将用户和物品映射到同一向量空间，通过向量相似度检索候选。核心是双塔模型。

  • 双塔DSSM：最初用于语义匹配，后被引入推荐。用户塔和物品塔独立，最后一层输出embedding，在线通过内积或余弦相似度计算。训练时通常使用batch内负采样。
  • Youtube DNN：Youtube发表的经典召回模型，将推荐视为极多分类问题，使用softmax输出，负采样使用负样本队列或采样修正。其核心创新在于引入用户历史观看序列和搜索序列，通过平均池化得到用户向量。
  • 多兴趣召回：
    • MIND（Multi-Interest Network with Dynamic Routing）：使用胶囊网络动态路由机制，将用户历史行为聚类为多个兴趣向量，每个向量代表用户的一个潜在兴趣。检索时，对每个兴趣向量分别做ANN，合并结果。
    • ComiRec：基于注意力机制的多兴趣抽取，可控制兴趣数量，且训练更稳定。

案例：爱奇艺多兴趣召回实践
爱奇艺随刻推荐团队在多兴趣召回上进行了深入探索。他们经历了从PinnerSage（聚类多兴趣）到MOE多兴趣，再到基于Transformer的单激活多兴趣（类似MIND）的演进。

  • MOE多兴趣：引入多个专家网络，每个专家负责一个兴趣领域，用户特征经门控网络加权组合成多个兴趣向量。上线后，该召回源的CTR比全端平均水平高出28%，展均播放时长高出45%。
  • 单激活多兴趣：使用Transformer提取行为序列的多个表征，通过Disagreement Regularization约束兴趣向量间的差异性，降低多路召回结果重复度。实验显示，相比MOE，CTR再提升5%，重复度下降15%。

4.1.3 图召回

将用户和物品视为图中的节点，交互行为视为边，通过图嵌入学习节点表示。

  • Node2vec：通过随机游走生成序列，再用word2vec训练节点embedding。
  • EGES（Enhanced Graph Embedding with Side Information）：阿里提出的方法，在Graph Embedding基础上融入物品属性信息，缓解冷启动。
  • PinSage：Pinterest基于GraphSage改进的大规模图卷积网络，结合随机游走和卷积聚合，可处理数十亿节点。PinSage生成的embedding在Pinterest推荐中显著提升相关性。

4.1.4 序列召回

直接对用户行为序列建模，捕捉序列中的动态兴趣。

  • SR-GNN：使用门控图神经网络处理会话序列，预测下一个点击。
  • SASRec：基于Transformer的自注意力模型，每个物品与序列中其他物品交互，学习序列模式。在多个数据集上超越GRU4Rec。

4.1.5 召回融合

多路召回产生多个候选集，如何融合成一个统一列表？常见方法：

  • 瀑布模型：按固定优先级依次召回，直到凑足数量。简单但可能丢失优质结果。
  • 加权融合：给每路召回结果赋予权重（可学习），按加权分数排序。
  • 模型融合：将召回结果作为特征输入一个轻量级模型，学习融合权重。

案例：阿里云推荐平台的召回融合
阿里云推荐平台支持用户自定义多路召回，并提供“召回融合策略”功能，可配置权重、去重规则、多样性控制。平台内置了基于LR的融合排序模型，自动学习各路召回的贡献，相比固定权重，CTR提升3-5%。

4.2 排序算法

排序阶段的目标是对召回的候选集进行精准打分。模型复杂度和效果逐步提升。

4.2.1 特征工程

特征是排序模型的基础。常见特征类别：

  • 用户特征：用户ID、年龄、性别、地域、活跃度、历史统计（过去7天点击率）。
  • 物品特征：物品ID、类别、标签、作者、发布时间、历史统计（点击率、曝光量）。
  • 上下文特征：当前时间、是否周末、网络类型、设备型号。
  • 交叉特征：用户-物品交叉特征，如用户是否看过该作者的视频，用户与物品类别的匹配度。
  • 序列特征：用户最近点击的N个物品ID，作为序列输入模型。
  • 多模态特征：图像embedding、文本embedding（通过预训练模型如ResNet、BERT提取）。

4.2.2 模型演进

  • Wide & Deep：Google提出，Wide部分学习记忆能力（线性模型+特征交叉），Deep部分学习泛化能力（DNN），两者联合训练。广泛应用于早期CTR预估。
  • DeepFM：用FM替代Wide部分的LR，自动学习二阶特征交叉，效果优于Wide&Deep。
  • xDeepFM：引入CIN（Compressed Interaction Network）显式学习高阶特征交叉，进一步提升效果。

序列建模：

  • DIN（Deep Interest Network）：阿里提出的注意力机制，根据候选物品对用户历史行为进行加权池化，捕捉与当前候选相关的兴趣。实验显示，DIN相比不加注意力的模型，AUC提升0.5%+。
  • DIEN（Deep Interest Evolution Network）：在DIN基础上，引入GRU建模兴趣演化过程，进一步捕捉兴趣的动态变化。

多任务学习： 推荐往往需要同时优化多个目标，如CTR和CVR，或CTR和时长。多任务学习模型共享底层表示，通过特定任务网络输出多个分数。

  • MMoE（Multi-gate Mixture-of-Experts）：多个专家网络+门控网络，每个任务学习不同的专家组合权重，有效缓解任务冲突。在Google广告系统中，MMoE相比单任务模型，AUC提升1-2%。
  • PLE（Progressive Layered Extraction）：腾讯提出的改进版，通过分层提取共享和任务独有特征，进一步提升多任务效果。
  • ESMM（Entire Space Multi-task Model）：阿里提出的CVR预估模型，利用CTR和CTCVR作为辅助任务，解决CVR建模中的样本选择偏差和稀疏性问题。

最新进展：

  • SIM（Search-based Interest Model）：阿里提出的两阶段兴趣检索模型，第一阶段从长序列中检索top-K相关兴趣，第二阶段精细建模。可处理长达数万的行为序列。
  • UBR4CTR（User Behavior Retrieval for CTR）：通过检索用户历史中与当前候选最相似的行为，作为模型输入，提升CTR预估精度。

4.2.3 模型训练优化

  • 大规模稀疏参数训练：Embedding层通常占据模型绝大部分参数，如何高效存储和更新是关键。常用方法：
    • 使用HugeCTR或TensorFlow的Embedding API，支持分布式Embedding。
    • 采用LazyAdam等优化器，只更新出现过的Embedding。
  • 分布式训练框架：
    • Parameter Server架构：适用于稀疏模型，worker计算梯度，server更新参数。
    • AllReduce架构：适用于稠密模型，如Horovod。
  • 在线学习：部分系统支持实时流式训练，模型分钟级更新，捕捉最新趋势。

4.3 重排序与策略

4.3.1 多样性算法

  • MMR（最大边际相关性）： 
    score_i = λ * rel_i - (1-λ) * max_{j in selected} sim(i,j)
    每次选择使上式最大的物品加入结果集。λ控制相关性和多样性的权重。
  • DPP（行列式点过程）： 给定候选集，DPP选择一个子集Y，使得P(Y) ∝ det(L_Y)，其中L是半正定矩阵，L_ij = rel_i * rel_j * sim(i,j) 的某种组合。选择子集等价于最大化行列式，鼓励选择高质量且互不相似的物品。常用贪婪算法逐步添加使行列式增量最大的物品。

工程实现对比：

  • MMR计算简单，适合在线实时计算。
  • DPP效果更好，但计算复杂度O(N^3)，通常用贪婪近似O(N^2M)，M为最终列表长度。可离线预计算部分结果。

4.3.2 上下文感知

  • 已曝光过滤：记录用户最近曝光的物品ID，在重排时排除。
  • 滑动窗口去打散：在滑动窗口（如过去10个结果）内，同一类别的物品不能超过K个。
  • 位置偏差校准：由于用户倾向于点击靠前的结果，模型预测的点击率可能高估前列物品的真实相关性。可用PAL（Position-Aware List）等方法，学习位置偏置因子，校准预测分数。

4.3.3 业务约束

  • 流量调控：在某些场景下，需要控制不同类别或作者的流量占比。可通过在重排阶段动态调整某些物品的权重实现。
  • 价格敏感度：电商推荐中，用户对价格敏感，可结合用户历史购买价格区间调整物品排序。
  • 合规过滤：根据法律法规过滤违规内容。

5. 业务专题：多场景、多目标、冷启动等实战

5.1 多场景推荐

大型互联网公司通常有多个业务场景，如首页推荐、详情页相关推荐、搜索后推荐等。如何在不同场景间迁移知识和统一建模？

5.1.1 跨域/跨场景迁移

  • 迁移学习：先用主场景数据预训练模型，然后在目标场景微调。例如，用视频推荐数据预训练用户Embedding，再用于电商推荐。
  • 共享底层+场景特定层：模型底层共享，上层分场景独立。训练时联合优化。
  • 场景embedding：将场景ID作为特征加入模型，让模型自动学习场景差异。

5.1.2 场景个性化

  • 场景感知模型：在模型中引入场景特征（如当前页面、tab），并做特征交叉。
  • 场景化拆分网络：每个场景有自己的专家网络，同时有共享专家，通过门控网络融合。

案例：快手多场景推荐
快手拥有多个推荐场景（发现页、关注页、同城页）。他们采用多任务多场景联合建模框架，共享底层Embedding和部分专家，每个场景有自己的任务塔。实验表明，联合建模相比单场景建模，各场景CTR平均提升3-6%，冷启动新场景更快收敛。

5.2 多目标优化

5.2.1 目标定义

常见推荐目标：

  • CTR（点击率）
  • CVR（转化率，如购买、下载）
  • 时长（停留时间）
  • 完播率
  • 互动（点赞、评论、收藏）
  • 多样性、新颖性等

5.2.2 多目标融合

  • 加权和：将各目标分数线性加权，权重人工调优或通过贝叶斯优化。简单但难以处理目标间冲突。
  • 帕累托最优：寻找一组非支配解，在提升一个目标时不降低其他目标。常用多目标进化算法或基于梯度的多目标优化。
  • 基于强化学习的动态融合：将融合权重作为策略网络输出，以长期回报（如留存）为目标进行训练。

案例：快手OneRec的强化学习方案
快手OneRec系统引入强化学习进行多目标偏好对齐。他们构建了包含偏好奖励（用户点赞、收藏）、格式奖励（输出格式合规）和业务奖励（时长、GMV）的综合奖励系统，采用改进的ECPO算法进行训练。在本地生活场景中，该方案推动GMV暴涨21.01%，新客获取效率提升23.02%。

5.2.3 延迟反馈建模

转化行为（如下单）通常发生在点击后数小时甚至数天，导致训练样本中的标签延迟。常用方法：

  • 时间窗口划分：设定一个等待窗口，窗口内未转化视为负样本，窗口外转化仍计入正样本。
  • 延迟反馈模型：如DFM（Delayed Feedback Model），建模转化概率随时间的分布。

5.3 冷启动

5.3.1 用户冷启动

新用户没有任何行为，如何推荐？

  • 基于人口属性：根据年龄、性别、地域等推荐该群体热门内容。
  • 兴趣探索：使用Bandit算法（如汤普森采样、UCB）在新用户前几次请求中试探不同类别内容，快速学习兴趣。
  • 快速收敛策略：利用其他场景的行为（如注册时的兴趣选择）快速初始化用户向量。

5.3.2 物品冷启动

新上传的物品没有交互数据，如何推给合适的人？

  • 基于内容理解：提取物品的多模态特征（图像、文本、音频），与用户历史偏好内容进行相似度匹配。
  • 利用历史统计：参考同作者、同类目物品的统计特征作为冷启动估计。
  • 试探性曝光：将新物品随机小流量曝光给部分用户，收集反馈数据后再进入主模型。

5.3.3 系统冷启动

新上线推荐系统或新业务线，数据稀疏，如何启动？

  • 迁移学习：从其他领域（如搜索、广告）迁移用户兴趣模型。
  • 元学习：学习一个初始化模型，使得在新任务上少量样本即可快速适应。MAML等算法在冷启动问题上有应用研究。
  • Bandit + 内容理解：结合上下文Bandit和内容特征，探索利用平衡。

5.4 可解释性与公平性

5.4.1 可解释推荐

用户不仅需要推荐结果，还想知道“为什么推荐这个”。常见方法：

  • 基于特征的归因：用SHAP、LIME等方法解释哪些特征对预测贡献大。
  • 生成式解释：用模板或生成模型生成自然语言解释，如“因为你之前喜欢科幻电影，所以推荐《流浪地球》”。

5.4.2 公平性与去偏见

推荐系统容易放大数据中的偏见：

  • 位置偏差：用户倾向于点击靠前的结果，导致模型认为前列物品更相关。可用PAL、随机交换等方法消除。
  • 选择偏差：用户只对部分物品有反馈，未曝光的物品可能也相关，但模型无法学习。可用IPS（逆倾向评分）或DR（双重鲁棒）方法修正。
  • 流行度偏差：热门物品获得更多曝光，形成马太效应。可对样本进行re-weighting，或引入流行度特征让模型学习偏差并剔除。

6. 未来趋势与总结

6.1 未来技术趋势

6.1.1 大语言模型与推荐系统的结合

LLM在自然语言理解、推理、生成方面展现强大能力，为推荐系统带来新范式。

  • LLM for Rec：用LLM生成用户兴趣画像、物品描述，或直接作为排序模型。例如，将用户历史行为拼接成文本，输入LLM预测下一个兴趣。
  • 生成式推荐：不再通过“召回-排序”流水线，而是用Encoder-Decoder模型直接生成推荐列表。如快手OneRec系统，将推荐任务建模为序列生成任务，用T5-style模型生成item id序列。
    • OneRec将传统架构压缩为端到端生成式模型，算子从1.5万精简至1200个，运营成本降至传统方案的10.6%。
    • 实验证明，生成式推荐存在Scaling Law，随着参数量（如2.6B）增长，效果持续提升。
  • 推理能力注入：LLM的上下文学习和推理能力可用于解决冷启动、多场景迁移等问题。例如，OnePiece框架尝试在item ID序列上构建“上下文工程”，让推荐模型像LLM一样进行“举一反三”推理。

6.1.2 端上智能与个性化

随着终端算力增强和隐私法规趋严，部分推荐计算下沉到端上成为趋势。

  • 端侧推理：在手机端运行轻量级模型，利用本地数据实时更新，无需上传隐私。
  • 联邦学习：多端协同训练模型，只上传梯度，保护用户隐私。
  • 个性化：端上模型可根据每个用户的本地行为做个性化微调，实现“千人千模”。

6.1.3 强化学习在流量调控中的深度应用

强化学习可用于长期回报优化，如用户留存、LTV。在流量调控中，RL可学习如何动态调整不同内容的比例，最大化全局收益。

6.1.4 多模态统一模型

图像、文本、音频等多模态信息融合，构建统一的用户和物品表示。如CLIP模型对齐图像和文本，可用于跨模态召回。多模态预训练模型（如BERT、ViT）提取的特征可作为推荐系统的输入。

6.2 总结与团队借鉴

回顾本次分享，我们看到了推荐系统从传统多级流水线到端到端生成式架构的跃迁。以下是对团队可落地的几点建议：

  1. 架构演进应小步快跑：不要盲目追求大而全的架构。从垂直拆分（如得物DGraph）解决资源瓶颈，逐步引入分布式和智能化升级。每步都要有明确的目标和收益评估。
  2. 算法迭代需业务导向：所有算法改进都应服务于明确的业务指标（CTR、时长、GMV等）。从爱奇艺的多兴趣召回、快手多目标优化案例可以看出，模型创新必须紧密结合业务场景，通过A/B测试验证效果。
  3. 强化ABTest文化与数据一致性：建立可信的ABTest平台是验证效果的基础。必须保证离线评估与线上效果的一致性，避免“离线涨线上跌”的尴尬。建议建设特征存储和在线样本生成系统，确保离在线特征逻辑一致。
  4. 重视数据、算法、工程三位一体：推荐系统的竞争是系统性竞争，算法再好，若工程无法支撑也是空中楼阁。工程师需要理解算法原理，算法工程师需要关注工程约束，双方紧密协作。

最后，推荐系统的发展日新月异，我们应保持学习和探索的热情，拥抱生成式推荐、大模型融合等新技术，为业务创造更大价值。

7. Q&A

预留时间供听众提问，可准备几个常见问题备用

  • 如何解决线上模型效果与离线评估不一致？

    • 常见原因：特征不一致（离线特征与线上实时特征有差异）、样本分布不一致（线上环境变化导致数据分布偏移）、评估指标不一致（离线用AUC，线上看CTR）。解决方法：建设特征一致性校验平台，进行线上回放模拟，离线评估时采用与线上一致的采样逻辑。

  • 在资源有限的情况下，优先优化召回还是排序？

    • 取决于当前瓶颈。如果召回率低，大量优质物品未进入候选，应先优化召回；如果召回结果已覆盖大部分相关物品，但排序不够精准，则优先优化排序。通常可通过召回覆盖率分析和排序AUC诊断。初期建议召回和排序并行小步迭代。

  • 实时计算与离线计算的矛盾如何调和？

    • 实时计算追求低延迟，但可能牺牲准确性和复杂度；离线计算可以复杂但延迟高。调和策略：采用Lambda架构，离线计算全量数据得到基准特征和模型，实时计算增量数据更新，两者融合。同时，通过近线层（分钟级计算）作为缓冲，减轻实时压力。

报告结束
感谢聆听！

avatar
文章
阅读
粉丝