别再迷信离线了：流 + 在线模型，才是实时推荐的正解

说句实在的，这几年我看过太多“推荐系统架构图”，画得跟航母一样，结果一问——
👉 推荐结果 10 分钟更新一次
👉 模型一天一跑
👉 用户刚点完你推荐的内容，系统还当他没点

这玩意你敢叫“实时推荐”？
我不敢。

所以今天这篇，我想聊点更偏工程、更偏实践的东西：
👉 流式计算 + 在线模型部署，怎么真正落地一个实时推荐系统

不吹概念，不堆名词，咱就按“能不能上线、能不能抗压、能不能挣钱”这个标准来聊。

一、先泼一盆冷水：你真的需要“实时推荐”吗？

先说句可能得罪人的话：

90% 的业务，根本用不上“毫秒级实时推荐”

但——
剩下那 10%，不用就等死。

什么场景真需要？

• 信息流 / 短视频（兴趣变化极快）
• 电商首页（刚搜完“奶粉”，你还给我推路由器？）
• 广告投放 / 风控推荐
• 运营干预极强的内容平台

这些场景有个共同点：

用户行为一发生，就应该立刻影响推荐结果

这就决定了：
👉 离线特征 + 离线模型 = 天生有延迟

所以，实时推荐的核心不是“模型多牛”，而是——

数据能不能立刻流动起来

二、实时推荐的核心骨架：别把问题想复杂了

我先给你一个极度接地气的拆分：

实时推荐系统 = 三条流水线

1. 行为流：用户在干嘛
2. 特征流：行为如何变成特征
3. 模型流：特征如何影响推荐

画成一句话就是：

用户行为 → 流式计算 → 实时特征 → 在线模型 → 推荐结果

我们一个个拆。

三、第一条命脉：行为流，别再只当日志用了

很多团队的问题就出在第一步：

行为日志 = 落 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 分钟生效

对用户来说，都是肉眼可感知的提升。

所以如果你问我建议：

别一上来就追求完美实时
先把“流 + 在线模型”跑起来

能跑、能稳、能赚钱，
这才是一个推荐系统该有的样子。