Python短视频推荐系统设计与实现：架构、算法与工程实践

1. 从零到一：短视频推荐系统的设计与实现

做短视频相关的项目有一段时间了，这类项目的核心其实不在“会写Python”，而在于“理解推荐系统在一个真实场景下是怎么运转起来的”。今天想完整拆解一下基于Python的短视频推荐系统，从架构设计到算法选型，再到工程实现和上线后的优化，把整个过程里踩过的坑和沉淀下来的经验一并分享。这篇内容适用于正在做毕设、课程设计，或者准备转行推荐算法方向的开发者，也适合短视频产品团队里想快速搭建一套推荐底座的工程师。

先说清楚这个项目解决的是什么问题：短视频平台的内容数量巨大，用户刷视频的动作又快又轻，系统要在毫秒级内从海量候选中找出用户当前最可能愿意看完、愿意互动的那一批视频。和电商推荐、新闻推荐不同，短视频推荐有几个非常鲜明的特点：内容生命周期极短，一条视频的热度可能在几小时内就从峰值跌落；用户兴趣漂移快，今天爱看萌宠，明天可能就切换到了汽车评测；完播率和互动率是核心指标，而不是简单的点击率。这些特点决定了我们不能简单套用传统的协同过滤或者纯CTR预估模型，而是要在架构和策略上做针对性设计。

提到推荐系统，很多新手第一反应是“我要训练一个模型”。实际做过之后就会发现，模型只是整个系统的一部分，甚至不是最复杂的那部分。一个能够稳定运行的短视频推荐系统，至少包含数据处理管道、召回层、排序层、策略层（比如去重、多样性打散、冷启动管理）、监控和日志体系。这五个部分像流水线一样协作，任何一个环节出问题，都会直接反映到用户留存和播放时长上。

1.1 短视频场景对推荐系统提出的特殊挑战

我把短视频推荐和传统推荐做了个对比，方便你看清楚为什么不能直接套模板：

短视频场景下，用户的行为信号信噪比很低。用户不点赞不代表不喜欢，可能就是单纯划过去了；用户完播了一条视频，也不一定表示对这个作者的所有内容都感兴趣。这就导致我们在做特征工程和样本构建时，必须想清楚“到底用什么行为来代表正样本”这个底层问题。

1.2 这个项目要解决的核心需求

基于Python落地一套短视频推荐系统，核心需求可以拆成四块：

• 数据层：采集或模拟用户行为数据（曝光、点击、完播、点赞、评论、转发），清洗后构建训练样本和特征宽表。
• 召回层：从百万级视频库中快速筛出数百个用户可能感兴趣的候选。要求速度快、覆盖面广，宁可召回噪音多，也不能漏掉好内容。
• 排序层：对召回结果做精细化打分，融合用户特征、视频特征、上下文特征，输出最终推荐顺序。这里需要模型有足够强的表达能力。
• 策略层：处理业务规则，比如同一作者视频连续出现不能超过N条、已看过的视频要过滤、新视频要有冷启动曝光机会。

换句话说，这个项目不是“训练一个模型就完事”，而是一个完整的闭环工程。我见过很多同学把全部精力放在调模型参数上，结果候选集质量很差，精排模型再强也救不回来。正确的思路是先把管道跑通，再逐层优化。

2. 系统架构与关键技术选型

我在设计这套推荐系统时，参考了业界主流的推荐架构模式，但做了一些针对短视频场景的简化。整体架构是经典的“召回 + 粗排 + 精排 + 重排”，不过考虑到部署成本和数据规模，我把粗排这一步稍微简化了，用双塔模型配合向量检索来实现召回和粗排的合流，精排用深度学习排序模型。

2.1 架构分层的设计逻辑

这里有一个值得展开的点：为什么大厂推荐架构都要做召回、粗排、精排三层，而不是一个模型直接搞定？

原因在于性能和效果的平衡。一个复杂的深度学习排序模型，单次推理需要几毫秒甚至几十毫秒。如果对全量视频库（比如百万级）都跑一遍精排，延迟会大到无法接受。所以标准的做法是：

1. 召回层：用轻量级模型（如双塔、向量检索）从全量候选中快速捞回几百条。这一步追求的是“不能漏”，允许有一定噪音。
2. 粗排层：用稍微复杂一点的模型（如浅层网络、轻量GBDT）对上一步的几百条再做一次筛选，压缩到几十条。
3. 精排层：用完整的深度学习模型对最终几十条做精细打分，追求“排序准”。
4. 重排层：应用业务规则和多样性算法，调整最终展示顺序。

在我们的场景下，因为数据量还没到需要分布式计算的程度，Python生态完全可以撑得住，所以我把粗排的职能合并到了召回阶段——用双塔模型内积打分完成粗筛，候选集控制在200条以内，再由精排模型负责最终的精细化排序。这个简化的收益是工程实现容易得多，但是代价是召回的batch内损失函数选择要更加谨慎，不小心容易让整个系统偏向热门内容。

2.2 为什么选择Python技术栈

做推荐系统不是只有Python一个选择，Java和Scala在工业界也大量使用，但Python在以下几个维度对这个项目来说优势太明显：

• 算法迭代速度：推荐算法的实验频率非常高，经常是一周要跑十几个实验组。Python配合NumPy、Pandas做特征处理和模型验证，效率远超编译型语言。
• 深度学习框架生态：TensorFlow、PyTorch的Python接口是这个领域的通用语言，社区里能参考的推荐模型实现几乎都是Python写的，踩坑时搜到的解决方案也最丰富。
• 全链路语言统一：数据处理用Pandas，模型训练用PyTorch，在线服务用Flask/FastAPI，特征存储用Redis，这些Python都能无缝衔接。不用在工程语言和算法语言之间做切换，开发和调试效率大幅提升。

当然，Python的短板也很明显，CPU密集型任务性能不如Java。所以关键接口上要合理设计，比如把计算量大的向量检索交给FAISS这样的库来处理，而不是自己写循环遍历。

2.3 关键工具组件选型

我在实际项目中选型的核心组件如下，你完全可以参考这一套来搭建：

这套组合的优点是每个组件都足够成熟、文档丰富，不会出现“方案很先进但没人踩过坑”的情况。我个人建议你在起步阶段不要追求技术上的“新奇特”，稳定跑通比什么都重要。

3. 数据准备与特征工程实战

推荐系统圈子里有句话叫“特征决定了效果的上限，模型只是逼近这个上限”。短视频推荐系统里的特征，我把它分为三大类：用户特征、视频特征、上下文特征。下面详细说下每一类怎么构建、有哪些坑。

3.1 用户行为数据的采集与样本构建

用户行为日志是推荐系统最重要的原材料。在一些课程项目里，大家会直接拿公开数据集（如某视频网站的点击日志）来实验，但真实场景里，我们要自己设计埋点方案。

对于短视频，最重要的行为类型和对应的权重如下：

• 曝光：视频展示给用户。注意曝光样本不能当正样本，它是构造负样本的基础。
• 有效播放：播放时长超过3秒。这是衡量用户是否被吸引的关键动作。
• 完播：视频播放达到90%以上。这是短视频场景下最强的正信号。
• 点赞、评论、转发、关注：互动行为的权重依次升高，代表用户的深度认可。

样本构建的核心逻辑是给每一个曝光样本打标签。我当时用的规则是：

• 正样本：完播，或者播放时长超过视频总时长的一半且有点赞/评论行为。
• 负样本：曝光但播放时长不足3秒。

这里有个容易被忽略的细节：负样本不是随便抽的。如果直接把所有曝光未点击的样本都当负样本，模型会严重偏向热门视频，因为热门视频曝光量天然很大。业界常用的做法是对负样本按曝光次数降采样，也就是一条视频被曝光越多，它作为负样本被保留的概率越低。我当时设置的概率是p = min(1, 100 / expose_count)，实测下来能明显缓解热门偏置。

3.2 用户特征与视频特征的设计细节

用户侧特征，我用了三类：

• 基础统计类：用户的历史平均完播率、互动率、偏好类目分布（用TF-IDF向量表示）。
• 行为序列类：最近N条交互过的视频ID序列，配合视频的类目和标签做Embedding后拼接。这里需要说明的是，行为序列是短视频推荐效果最显著的特征之一，它能捕捉用户短期兴趣的漂移。
• 动态兴趣类：实时统计用户最近半小时内的交互类目分布。短视频用户的兴趣变化非常快，昨天喜欢看的内容今天不一定喜欢，所以短期窗口统计有时比长期统计更有用。

视频侧特征，核心是内容理解：

• 视频本身的多模态特征：标题文本的Embedding、封面图的视觉特征、音频特征。在完整实现中，我用的是预训练的BERT提取标题语义向量，用预训练的ResNet提取封面特征。
• 视频的类目和标签：通过规则 + 分类模型打标，保证同一条视频可以归属多个类目。
• 运营侧特征：视频发布时间、作者粉丝量、作者历史平均完播率。这类特征特别重要，因为短视频有明显的马太效应，作者的历史表现对新视频的冷启动有很强的指示作用。

上下文特征，指的是推荐时刻的环境信息：

• 当前时间（时段、是否周末）。
• 用户当前网络环境（WiFi还是移动网络，关系到用户是否更倾向于观看长视频）。
• 设备信息（屏幕尺寸、操作系统版本），不同设备上用户行为差异很明显。

3.3 特征工程中三个必须注意的问题

第一，特征穿越是最容易犯的错误。比如用视频未来的完播数据来预测它过去的排序得分，这在离线实验里会产生虚高的效果提升。正确做法是特征拼接时严格按照时间戳对齐，只用预测时刻之前能拿到的信息。我当时踩过这个坑，用了全量的视频统计特征做实验，离线AUC高了三个点，上线后毫无变化，白高兴一场。

第二，特征覆盖率要实时监控。短视频场景下，新视频在发布的前几个小时内几乎没有任何统计特征，如果模型强行依赖统计特征，新视频的得分会被压得很低。所以我会给所有统计特征增加一个“缺失标志位”，让模型自己学会在特征缺失时回退到其他信号上。

第三，连续特征要分箱离散化再Embedding。实战中，直接输入原始数值效果往往不如离散化之后做Embedding。原因在于推荐场景的特征和标签之间多为非线性关系（比如完播率在0.9到1.0区间对预测结果的边际贡献远大于0.5到0.6），分箱可以增强模型的表达能力。我一般用等频分箱，把每个连续特征切成100个桶，再做Embedding。

4. 召回层：双塔模型与向量检索

召回层的目标是从上百万条视频里快速筛出几百条候选。这里我用的是目前工业界最主流的双塔召回模型，下面把实现原理和参数配置都拆开讲。

4.1 双塔模型的核心思想：把用户和视频映射到同一向量空间

双塔模型的“双塔”指的是两侧神经网络分别处理用户侧特征和视频侧特征，最后各自输出一个固定维度的向量。训练时让“用户向量”和“正样本视频向量”尽可能靠近，“用户向量”和“负样本视频向量”尽可能远离。模型训练好之后，视频塔的输出向量可以离线算好存起来，线上推理时只需要实时计算用户向量，然后去向量库里做最近邻检索就行。

这个架构之所以被大规模使用，核心原因是在线性能和数据更新的解耦。视频特征每天的更新频率远低于用户实时行为，离线把视频向量全部算完存进FAISS索引，在线查询就不会有多大的计算压力。而用户向量随着用户行为实时变化，但计算量只有一次前向推理，开销也可控。

用生活化类比来说，双塔召回就像是在建一个巨大的图书馆。视频侧把所有书的内容浓缩成一个编号放进目录卡片里，用户来借书时，系统先把用户的阅读偏好浓缩成一个向量，再拿着这个向量去卡片目录里翻找相近的编号。翻找的过程用的是近似最近邻检索，不需要一本一本地比对内容。

4.2 PyTorch代码实现双塔模型

下面给一个精简版的双塔召回模型代码，可以直接运行起来看效果：

import torch import torch.nn as nn class TwoTowerModel(nn.Module): def __init__(self, user_feature_dim, video_feature_dim, embedding_dim=64): super(TwoTowerModel, self).__init__() # 用户塔：多层全连接，逐步压缩到embedding维度 self.user_tower = nn.Sequential( nn.Linear(user_feature_dim, 256), nn.ReLU(), nn.Dropout(0.3), nn.Linear(256, 128), nn.ReLU(), nn.Linear(128, embedding_dim) ) # 视频塔：结构保持一致，保证向量空间可比较 self.video_tower = nn.Sequential( nn.Linear(video_feature_dim, 256), nn.ReLU(), nn.Dropout(0.3), nn.Linear(256, 128), nn.ReLU(), nn.Linear(128, embedding_dim) ) # 输出向量做L2归一化，方便用内积或余弦相似度度量 self.user_embedding_norm = nn.LayerNorm(embedding_dim) self.video_embedding_norm = nn.LayerNorm(embedding_dim) def forward(self, user_features, video_features): user_vec = self.user_tower(user_features) video_vec = self.video_tower(video_features) user_vec = nn.functional.normalize(user_vec, p=2, dim=1) video_vec = nn.functional.normalize(video_vec, p=2, dim=1) return user_vec, video_vec

训练时，我采用了batch内负采样的策略。一个batch里有N个用户和对应的N个正样本视频，用户i的正样本是video_i，负样本是该batch内其他所有用户的视频。这样一次前向计算就能构造出N×N的相似度矩阵，极大提升了训练效率。

def sample_loss(user_vec, video_vec, temperature=0.05): # user_vec: [batch_size, dim] # video_vec: [batch_size, dim] logits = torch.matmul(user_vec, video_vec.T) / temperature labels = torch.arange(user_vec.size(0), device=user_vec.device) loss = nn.functional.cross_entropy(logits, labels) return loss

这里temperature=0.05是有讲究的。温度参数越小，softmax输出的分布越尖锐，模型会更用力地把正样本从负样本中分开。但温度太小容易造成训练不稳定，我试过0.01，loss波动明显加大，0.05到0.1之间是比较稳的区间。

4.3 FAISS向量检索：从理论到落地的关键一跳

模型训练完成后，要把全量视频的向量灌入FAISS建立索引。FAISS支持多种索引方式，我对比过效果之后选了IndexIVFFlat，它的核心思路是先粗聚类再精确检索。

流程很简单：

1. 将全部视频向量用K-Means聚成nlist=4096个类。
2. 查询时先找到用户向量最近的若干个聚类中心，再在这几个类内部做全量精确计算。
3. 设置nprobe=32，表示检索时搜索最近邻的32个聚类中心。

这样查询性能和精度能取得很好的平衡。全量100万条视频索引建立耗时大约10分钟，单次查询延迟在5毫秒左右，完全符合在线服务要求。

import faiss # 假设video_embeddings是全部视频的向量矩阵，shape=[num_videos, dim] dim = 64 nlist = 4096 quantizer = faiss.IndexFlatIP(dim) index = faiss.IndexIVFFlat(quantizer, dim, nlist, faiss.METRIC_INNER_PRODUCT) index.train(video_embeddings) index.add(video_embeddings) # 查询 index.nprobe = 32 scores, indices = index.search(user_embedding, k=200)

这里需要强调一个细节：FAISS索引要定时重建。短视频的场景下，每天新增的视频量非常大，视频的语义也在持续变化，如果索引不更新，召回的新视频会严重滞后。我当时设计的是每30分钟增量加入新视频向量，每隔6小时用最近的数据全量重建一次索引。

4.4 召回阶段的冷启动处理

冷启动是短视频推荐最头痛的问题之一，新视频没有行为数据，双塔模型给它的向量往往很平庸。我当时的策略是“保底召回 + 试探曝光”的组合：

• 保底召回：新视频在发布后的第一小时内，直接分配给它的类目下的活跃用户，保证基础曝光量。
• 试探曝光：对曝光后的新视频实时回收反馈信号，一旦完播率达标，立即将其加入常规双塔候选池。

这个策略看起来简单，但实际执行中要考虑一个问题：冷启动视频不能抢走头部视频的流量。所以我额外加了一个流量配额机制，新视频仅在召回候选池的头部替换少量位置，保证整体推荐质量不崩塌。

5. 排序层：从CTR预估到多目标融合

召回决定了推荐的广度，排序决定了推荐的精度。短视频场景下，排序层面对的核心挑战是多目标优化——一个视频是否值得推给用户，不能只看点击率，还要看它能否带来完播、点赞、评论、关注。单纯优化某一项目标，一定会导致整体体验失衡。

5.1 排序模型的选择与输入设计

排序阶段我选用了深度模型，输入特征是召回阶段特征的精化版。结构上采取了三层全连接加多个输出头的设计。这里给出模型骨架：

class RankingModel(nn.Module): def __init__(self, feature_dim, num_tasks=4): super(RankingModel, self).__init__() self.shared_layer = nn.Sequential( nn.Linear(feature_dim, 512), nn.ReLU(), nn.Dropout(0.3), nn.Linear(512, 256), nn.ReLU() ) # 每个任务独立的塔 self.task_towers = nn.ModuleList() for _ in range(num_tasks): tower = nn.Sequential( nn.Linear(256, 128), nn.ReLU(), nn.Linear(128, 1) ) self.task_towers.append(tower) def forward(self, x): shared = self.shared_layer(x) outputs = [torch.sigmoid(tower(shared)) for tower in self.task_towers] return outputs

训练时，四个任务分别对应：点击率、完播率、互动率、关注率。每个任务有自己的标签和损失函数，共享底层特征表示。这种“共享底层 + 独立输出头”的设计在多任务学习中被称为Hard Parameter Sharing，优势是能减少过拟合、节省参数量，同时让不同任务之间互相补充信息。比如，点击率任务学到的高层特征对完播任务也是有用的，因为能点击的内容往往在标题和封面上有吸引力，这些信号同时也影响完播。

5.2 样本权重与延迟反馈的处理

排序模型的样本构建要比召回阶段精细很多。除了之前说的正负样本定义，还需要额外处理两个问题。

第一个是样本权重。不同行为的价值不同，完播一个视频和点击一个视频对用户后续行为的预测力是不一样的。我在训练时给样本设置了权重：曝光但未播放的负样本权重为1，完播的正样本权重为3，互动样本（点赞、评论）权重为5。权重过大会放大噪音，过小则模型学不到重点，这个比例是我在多轮实验中调出来的，不同数据分布下可能需要微调。

第二个是延迟反馈问题。用户观看视频后，可能隔了很久才点赞或评论。如果在用户观看时就把这条样本标记为负样本，模型的判断就会被污染。我的处理方式是给正样本一个“等待窗口”，例如用户完播后24小时内如果发生了互动，则该样本升级为正样本并重新进入训练流。这个机制虽然增加了数据管道的复杂度，但对互动率指标的提升非常明显，从我实测的数据看大约能涨2个点的相对提升。

5.3 多目标融合的权重设定

模型输出的是多个任务的预估分数（点击率、完播率、互动率、关注率），但最终线上展示给用户的是一个排序分。怎么把多个分数融合成一个总分，是需要仔细考虑的问题。我一开始用的是最简单的方法：加权求和。

final_score = 0.2 * pctr + 0.5 * pfinish + 0.2 * pinteract + 0.1 * pfavorite

但很快发现固定权重的问题：不同用户、不同场景下，各目标的重要性是会变化的。比如一个长期观看但从不互动的用户，互动率权重就应该降低；一个新用户，更需要有吸引力的内容来留存，完播率权重就应该提高。

后续优化中，我把固定权重改成了基于用户分群的动态权重。先离线把用户分为几个群（高活跃互动型、沉默观看型、新用户等），每个群单独标定一组权重。上线后AB实验显示，动态权重相对固定权重在人均时长上提升了约5%，这个提升幅度在大流量场景下已经非常有意义了。

5.4 排序层必须要解决的问题：特征拼接与实时性

排序模型的输入特征来自多个数据源，我在工程上把所有特征拼成一个固定长度的稠密向量。特征拼接的代码逻辑大家都会写，这里不赘述，但两个细节必须提醒：

• 特征ID映射要稳定：短视频平台的特征空间是不断变大的，每天都有新类目、新标签出现。如果特征映射表不及时更新，新特征会被当成未知ID处理，轻则损失信息，重则导致样本错乱。我每天定时全量刷新特征映射表，并为之做了版本管理。
• 实时特征要限定时间窗口：排序模型线上推理时，用了用户最近一段时间的实时行为特征（比如最近10条交互视频的类目分布）。这类特征的变化速度非常快，模型训练时用的窗口长度和线上必须一致，窗口不一致会直接造成离线离线效果差异巨大。

6. 策略层与工程化：重排、去重与冷启动机制

模型给出排序分之后，还不能直接把这个顺序推给用户。短视频信息流的体验要求非常高，一条内容不合适就可能导致用户划走。所以策略层是推荐系统里“看不见但感知最直接”的部分。

6.1 规则打散与多样性保证

如果严格按照模型分排序，结果往往会出现同一个作者的视频连续出现多条，或者同一个类目霸屏的情况。这是因为模型打分倾向于给相似视频高分，而用户在浏览时却需要内容节奏的变化。

我实现了两个核心策略：

• 同作者去重：同一作者的视频在用户信息流中连续出现不能超过2条。目的是避免信息流变成某个创作者的专场，破坏用户的新鲜感。实现时在重排阶段动态调整，每放一条视频进入最终列表，就检查它与前两条是否同作者。
• 类目打散：设定一个“滑动窗口”，窗口大小为6。窗口内任意类目的视频出现不能超过3条。这个策略能有效避免内容单调，对用户留存有明显帮助。

这里有一个值得展开的工程实现细节：打散不能只靠后处理硬插，那样会大幅牺牲模型分数。我参考了一些业内的做法，采用了一种贪心 + 惩罚项的方案：在重排阶段，每选择一个视频进入最终列表时，除了看模型分，还要看它与已选视频在作者、类目上的相似度，相似度高就打一个折扣。这样既保证了主要排序质量，又让多样性自然产生。

def rerank(candidates, model_scores, author_ids, category_ids, penalty=0.5): selected = [] selected_authors = [] selected_categories = [] for i in range(len(candidates)): best_idx = -1 best_score = float("-inf") for j in range(len(candidates)): if j in selected: continue score = model_scores[j] # 惩罚：与最近两条同作者则打折 if author_ids[j] in selected_authors[-2:]: score *= penalty # 惩罚：滑动窗口内同类目已出现多次则打折 window = selected_categories[-6:] if window.count(category_ids[j]) >= 3: score *= penalty if score > best_score: best_score = score best_idx = j selected.append(best_idx) selected_authors.append(author_ids[best_idx]) selected_categories.append(category_ids[best_idx]) return selected

6.2 已看过滤与去重机制

用户刷过的视频必须立即过滤，这条规则看起来很简单，但实现上有一个容易出问题的点：过滤要放在召回之前，而不是排序之后。如果先召回再过滤，候选集里大量位置被用户看过的视频占据，就算过滤掉，这部分的召回资源也浪费了，导致有效候选不足。正确做法是每次为用户生成推荐结果前，先加载该用户最近7天的浏览历史ID集合，在召回阶段查询时直接用这批ID做排除。

另外还需要考虑一个业务场景：用户刷新信息流时，不希望看到和刚才重复的内容。这个问题的解法除了“历史过滤”，还要配合session级别的去重。我用Redis存储每个用户当前会话最近看到的视频ID，每展示一条就追加，会话过期后自动清理。

6.3 在线服务架构与接口设计

在线服务用FastAPI搭建，核心接口就一个，接收用户ID和请求上下文，返回推荐视频列表。服务内部的处理流程是：

1. 从请求中解析用户ID和设备信息。
2. 从Redis加载用户特征、浏览历史、会话状态。
3. 调用双塔模型计算用户向量，用FAISS召回候选。
4. 拼接特征宽表，调用精排模型打分。
5. 执行重排策略（去重、多样性、冷启动流量配额）。
6. 返回最终视频列表。

整体链路要求耗时在100毫秒以内，实测稳定在80毫秒左右。压测时最大QPS能支撑到2000+，对于课程设计和中小规模应用完全够用了。

下面是精简版的接口代码：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class RecommendRequest(BaseModel): user_id: str device_type: str = "mobile" request_time: str = None @app.post("/api/recommend") def recommend(req: RecommendRequest): # 1. 获取用户特征 user_feat = get_user_features(req.user_id) # 2. 向量召回 user_vec = two_tower_model.encode_user(user_feat) candidate_ids, scores = faiss_index.search(user_vec, k=200) # 3. 过滤已看 candidate_ids = filter_history(candidate_ids, req.user_id) # 4. 精排打分 rank_scores = ranking_model.predict(candidate_ids, user_feat) # 5. 重排 final_ids = rerank(candidate_ids, rank_scores, author_map, category_map) return {"video_list": final_ids}

6.4 AB实验与效果评估体系

推荐系统的迭代绝对不能靠拍脑袋。每一个策略改动、每修改一个模型参数，都必须经过AB实验验证。我在这里搭建了一个轻量级的分流框架：用户ID哈希后按阈值分桶，实验组和对照组的流量比例可以动态调整。实验评估指标包括：

• 主指标：人均观看时长、人均完播数、次留率。
• 辅助指标：互动率、人均曝光数、作者侧的内容生态健康度。

这里有一个非常容易忽略的点：时长类指标容易被少数高时长用户拉高。所以我在统计人均观看时长时会同时看P50和P90分位数，如果P50没涨但P90涨了，说明只是头部用户观看变多，整体体验未必有提升。

7. 在线效果实测与多轮优化复盘

整个系统上线后，我在一个模拟短视频平台上做了持续一周的在线效果跟踪。这里分享几个关键数据和优化过程中的真实调整。

7.1 初始版本的效果基线

系统初始版本跑出来的数据如下：人均观看时长4.8分钟/天，完播率38%，互动率2.1%。这个数据在当时属于“能跑通但明显有优化空间”的水平。

第一轮迭代重点放在特征补全上。我把用户行为序列特征从最近10条扩展到最近30条，并加入了点击视频的场景信息（例如用户从哪个页面进入）。这个改动让人均观看时长提升了约6%。说明在推荐系统里，特征维度的丰富度对效果的贡献往往比模型结构调整来得更直接。

第二轮迭代重点放在负样本采样优化上。我把曝光次数大的热门视频在负样本中的占比做了进一步限制，同时对曝光次数极少的视频提升负样本权重。这一轮让完播率提升了约4%，但互动率没有明显变化。

第三轮迭代是上线了动态融合权重，针对不同用户群使用不同的目标融合系数。这轮改动对人均观看时长的提升是前三轮里最明显的，达到了约8%，并且没造成互动率下降，算是比较理想的优化。

7.2 过程中踩过的一个隐蔽陷阱：样本时间穿越

在第三轮实验里，我遇到了一个非常隐蔽的问题：离线评估显示效果提升非常显著，但线上AB实验毫无起色。查了很久才发现，原因是在特征工程中，我用了一条视频的“历史完播均值”特征，但在离线训练时这个均值是用全量数据计算的，包含了这条视频在预测时刻之后产生的完播行为。也就是说，离线训练时模型偷偷“看到了未来”，看起来效果当然好。而线上推理时特征变成了实时累计值，模型就这么失灵了。

修复方法也不复杂，做特征时严格按时间划分。每个样本的特征计算只使用该样本产生时刻之前的数据，绝不用未来的信息。这个坑建议所有做推荐系统的同学都留意，很多离线效果虚高都是这么来的。

7.3 线上长尾内容生态的变化

优化完线上效果之后，我还观察到另一个有意思的现象：推荐系统的流量分配开始向头部内容集中，具体表现是头部1%的视频获得了超过40%的曝光。这从短期看没有损害用户指标，但长期会带来内容生态问题——中小创作者没有曝光，创作热情下降，平台的内容供给会萎缩。

为了解决这个问题，我在策略层加了一个创作者维度公平性约束：控制单个作者在整体信息流中的曝光占比不超过某个阈值，超过则自动为该作者的视频降低推荐权重。这个策略上线后，头部作者的曝光占比从40%回落到25%，中尾部创作者的曝光明显提升，而用户侧的核心指标几乎没有变化。这验证了一个观点：推荐系统不仅要考虑用户满意度和商业目标，还要考虑内容供给方的利益，后者往往决定了平台的长期生命力。

8. 上线后的常见问题与排障实录

系统稳定运行之后，日常工作的重点就变成了监控和排查问题。我把线上最常遇到的几类问题和排查思路整理成了一份速查表。

这里展开讲一个线上案例。有一次系统报警显示iOS端用户的播放时长明显下降，而Android端正常。最初我们以为是模型问题，排查了一圈后发现，是线上的一处前端埋点改版，导致iOS端的曝光日志丢失了一部分，进而导致训练样本和实时特征都不完整。这个案例告诉我们：推荐系统的效果波动首先要怀疑数据链路，而不是模型本身。在做排查时有一条固定思路：先确认数据完整性，再验证特征一致性，最后才动模型和策略。

另外一个小技巧值得分享：为线上服务配置详细的日志，至少包含请求ID、用户ID、召回候选数、排序分数、最终结果列表、链路各阶段耗时。一旦出现用户反馈问题，可以通过请求ID定位到完整的处理链路，快速判断瓶颈和异常发生在哪一个环节。

9. 我在这个项目上的一点体会

做完这个短视频推荐系统，我对推荐工程的理解发生了不小的变化。以前写算法Demo的时候，总觉得模型结构越复杂越高级，注意力机制、图神经网络、强化学习，什么新用什么。但真正接触到完整的产品链路后才发现，推荐系统的核心竞争力不在模型有多炫，而在细节有多扎实。双塔模型可能只有一个隐藏层，精排模型也可能只是普通的全连接网络，但特征是否干净、负样本是否合理、去重策略是否严密、冷启动机制是否完善，这些才真正决定了用户体感。

如果现在让我重新做一个类似的推荐项目，我的侧重点会有明显不同。首先，数据管道和数据质量的建设优先级要远高于模型调参，没有干净的数据，一切模型创新都是空中楼阁。其次，策略层的规则打磨应该是和模型训练并行推进的，很多时候一个简单的打散策略比调整损失函数带来的体感提升更直接。最后，一套完善的监控体系是项目能不能长期稳定运行的分水岭，遗漏了它就会在线上不断踩坑。

我个人在实际操作中还有一个具体的建议：做推荐系统一定要保留一个“简单版本”作为对照基线。当实验结果复杂到难以判断效果归因时，快速回到基线版本跑一组对比，往往能帮你找出问题到底出在哪个环节。不要怕把系统做得简单，真正可怕的是复杂到没人能说清楚每个组件为什么存在。

这套系统后续还可以继续扩展的方向，比如引入图神经网络建模用户和创作者之间的多跳关系、用强化学习优化长期留存目标、在精排阶段直接建模刷新行为的位置偏差等。这些方向我后续也在尝试，等沉淀出可复现的结果后再继续分享。