别再迷信离线了：流 + 在线模型，才是实时推荐的正解
说句实在的，这几年我看过太多“推荐系统架构图”，画得跟航母一样，结果一问——
👉 推荐结果 10 分钟更新一次
👉 模型一天一跑
👉 用户刚点完你推荐的内容，系统还当他没点
这玩意你敢叫“实时推荐”？
我不敢。
所以今天这篇，我想聊点更偏工程、更偏实践的东西：
👉 流式计算 + 在线模型部署，怎么真正落地一个实时推荐系统
不吹概念，不堆名词，咱就按“能不能上线、能不能抗压、能不能挣钱”这个标准来聊。
一、先泼一盆冷水：你真的需要“实时推荐”吗？
先说句可能得罪人的话：
90% 的业务，根本用不上“毫秒级实时推荐”
但——
剩下那 10%，不用就等死。
什么场景真需要？
- 信息流 / 短视频（兴趣变化极快）
- 电商首页（刚搜完“奶粉”，你还给我推路由器？）
- 广告投放 / 风控推荐
- 运营干预极强的内容平台
这些场景有个共同点：
用户行为一发生，就应该立刻影响推荐结果
这就决定了：
👉 离线特征 + 离线模型 = 天生有延迟
所以，实时推荐的核心不是“模型多牛”，而是——
数据能不能立刻流动起来
二、实时推荐的核心骨架：别把问题想复杂了
我先给你一个极度接地气的拆分：
实时推荐系统 = 三条流水线
- 行为流：用户在干嘛
- 特征流：行为如何变成特征
- 模型流：特征如何影响推荐
画成一句话就是：
用户行为 → 流式计算 → 实时特征 → 在线模型 → 推荐结果
我们一个个拆。
三、第一条命脉：行为流，别再只当日志用了
很多团队的问题就出在第一步：
行为日志 = 落 Hive = 第二天算指标
兄弟，这叫“数据考古”。
实时推荐的行为流，必须是“活的”。
1️⃣ 行为事件怎么定义？
别搞太复杂，先把最关键的抓住：
{
"user_id": "u123",
"item_id": "v456",
"event": "click",
"ts": 1700000000
}
核心就三样：
- 谁（user）
- 对什么（item）
- 干了啥（event）
2️⃣ 行为进哪？
我个人的偏好：
- Kafka / Pulsar
- Topic 按业务拆
- 坚决不要一锅炖
user_behavior_click
user_behavior_expose
user_behavior_like
这一步的观点很明确：
行为数据，必须“先服务在线”，再服务离线
四、第二条主线：流式特征，才是实时推荐的灵魂
说句真心话：
80% 的推荐系统，慢在“特征更新”
模型再牛，特征是昨天的，一样白搭。
1️⃣ 用流算什么特征？
别一上来就搞 embedding，先把这些用好：
- 最近 N 分钟点击次数
- 最近一次点击时间
- 行为衰减分数
- 实时 CTR
这些特征简单、稳定、杀伤力极强。
2️⃣ 用 Flink 举个最接地气的例子
比如：最近 5 分钟点击次数
# PyFlink 思路示意
from pyflink.datastream import StreamExecutionEnvironment
from pyflink.datastream.window import SlidingEventTimeWindows
from pyflink.common.time import Time
env = StreamExecutionEnvironment.get_execution_environment()
stream = env.from_source(kafka_source, watermark_strategy)
(
stream
.key_by(lambda x: (x["user_id"], x["item_id"]))
.window(SlidingEventTimeWindows.of(Time.minutes(5), Time.seconds(30)))
.process(CountProcessFunction())
.add_sink(redis_sink)
)
你注意几个关键点：
- 窗口是滑动的
- 结果直接进 Redis / Feature Store
- 不是算完落 HDFS
这一步我的态度非常明确：
实时推荐，特征一定要“流算 + 在线存”
五、第三条命脉：在线模型，别再一天一更了
说到模型，很多人容易走极端：
- 要么全离线
- 要么上来就搞在线学习、强化学习
我个人更推崇一个现实主义方案：
离线训练 + 在线推理 + 轻量在线更新
1️⃣ 在线模型到底部署在哪？
常见方案：
- TensorFlow Serving
- TorchServe
- 自研 HTTP / gRPC 服务
模型结构也别太贪：
- LR / FM / DeepFM
- 特征可解释，延迟可控
2️⃣ 在线推理示例（伪代码）
def recommend(user_id):
features = feature_store.get(user_id)
score = model.predict(features)
return rank(score)
注意重点不是代码，是：
- feature_store 是实时的
- predict 是毫秒级的
- rank 是可控的
3️⃣ 我的个人观点（很重要）
99% 的业务，在线学习不是刚需
先把实时特征 + 稳定在线推理跑稳了，
比你搞一堆 fancy 的在线训练靠谱得多。
六、流 + 在线模型，真正难在哪？
说点掏心窝子的。
真正难的不是技术，而是这些：
1️⃣ 数据一致性
- 流里算的特征
- 模型里用的特征
- 离线回溯用的特征
三套一旦不一致，推荐效果你根本解释不了。
2️⃣ 延迟预算
你得非常清楚：
- Kafka 延迟多少
- Flink 窗口多久
- Redis 查询多久
- 模型推理多久
实时推荐不是“快”，而是“可预期地快”。
3️⃣ 组织心态
很多团队嘴上说实时，
心里还是“明天再算也行”。
这事儿，说白了是工程文化问题。
七、写在最后：别被“实时”两个字吓住
最后我想说一句很个人的话。
实时推荐系统，不是银弹。
它也不是为了炫技。
它真正解决的只有一件事：
让系统，对用户的“当下”更敏感一点
哪怕只是：
- 点击后 30 秒生效
- 行为后 1 分钟生效
对用户来说，都是肉眼可感知的提升。
所以如果你问我建议：
别一上来就追求完美实时
先把“流 + 在线模型”跑起来
能跑、能稳、能赚钱，
这才是一个推荐系统该有的样子。
